Software Performance 34th Edition

Spring 2014 GIS Software Performance 34th Edition

This section shares lessons learned about selecting and building effective GIS design solutions that satisfy operational performance and scalability needs. Software technology allows us to model our work processes, and provide these models to computers to optimize user workflow performance. The complexity of these models, the functions selected to generate our display, and how application functions are orchestrated to analyze and present information processing needs have a significant impact on computer system workload and subsequent performance and scalability.

For many years we focused our system architecture design consulting efforts toward identifying and establishing a hardware infrastructure that would support a standard implementation of Esri software technology. We developed platform sizing models based on consulting experience and customer implementation success. We updated our sizing models based on relative performance benchmark testing which focused on quantifying changes in critical processing loads introduced with each new software release. Today we have a Capacity Planning Tool that automates our system architecture design analysis enabling more refined and accurate performance management.

There are examples of GIS deployments that do not take advantage of system architecture design best practices. Systems are deployed with unresolved performance issues, and scalability is not well understood. In some cases performance issues are not identified before the production system is under critical peak loads, and often the platform solution or network infrastructure fails to meet mission performance needs. Resolving performance issues while in production can be expensive, both in terms of lost services and user productivity. Building a system design that addresses capacity planning needs can improve user productivity and reduced implementation risk. 

=Workflow baselines=

Workflow baselines provide a foundation for capacity planning. We discussed the various GIS software deployment patterns in Chapter 2 Software Technology. Each software deployment pattern provides a unique combination of hardware and network processing loads deployed within a component architecture that supports the system computing environment. Figure 3.1 provides an overview of the software and network components that impact the system architecture design. We will be discussing these components and their system configuration strategies throughout the System Design Strategies wiki. These are the primary components that work together to make up the system architecture design.

Software technology selection determines the software components that will participate in the selected workflow. Each software deployment pattern includes components that are installed on the computing system.
 * ArcGIS for Desktop workstation deployments. Software includes the Client, SDE, and DBMS components.  Client communicates over the network to the DBMS server.
 * ArcGIS for Desktop Citrix deployments. Software includes the terminal Client, WTS, SDE, and DBMS components.  Terminal client communicates over the network to the WTS server.
 * ArcGIS for Server deployments. Software includes the Client, Web server, SOC (GIS Server), SDE, and DBMS components. Web client communicates over the network to the Web server.

The workflow baseline identifies the medium system processing loads for a specific software technology pattern. These processing loads are expressed as display service times and network traffic per display on the various system components. The load profile (how the load is distributed across the software components) is fairly consistent for each software technology selection. The processing and traffic load intensity will vary within each technology deployment pattern based on display complexity and some additional key software configuration parameters we will discuss in this chapter.

A workflow baseline is established for each software technology pattern, identifying a medium complexity load for each of the system components for that workflow, for capacity planning purposes. The software baseline loads are established from analysis of benchmark test results and software deployment experience.

=Custom workflows=

Figure 3.2 shows how we can generate a custom workflow from a workflow baseline. The selected software technology baseline workflow loads are adjusted by some key performance parameters. Experience in design, testing, and tuning systems is used to establish relative performance adjustments that can be applied to the baseline to generate the custom workflow loads.

Each of the boxes in Figure 3.2 represents key performance parameters that will adjust the workflow loads on the system. These key performance parameters are decisions you will make in developing the map service. Performance baselines are adjusted based on the complexity of your data model or application functions, and display performance is determined by the final system architecture design selection. As you choose your display configuration the workflow processing loads (service times) will be adjusted accordingly.

=Software workflow recipe=

The software workflow recipe identifies the assumptions used to generate the workflow processing loads. The CPT Calculator is a tool developed for generating custom workflow service times (estimated system loads) directly from a defined software workflow baseline. The performance factors in the workflow recipe track the most critical parameters evaluated during our performance testing.

This chapter will describe each of the critical recipe components used to establish software component workflow service times, and show how to use the CPT Calculator to select appropriate project workflow performance targets.

There are two workflow recipe formats, one for GIS workflows and another for Imagery workflows.

GIS workflow recipe
Figure 3.3 shows the CPT cell headings and selections for a GIS workflow. The GIS workflow recipe provides metadata identifying software application design specifications selected for a GIS desktop or Web mapping service in the CPT Calculator Software Technology Performance Factors module.
 * The software selection establishes a medium workflow performance baseline.
 * The remaining recipe selections modify the performance baseline to represent the selected custom workflow.

"Best Practice: Performance adjustments are selected from look-up tables established from analysis of benchmark test results. " 

Image service workflow recipe
Figure 3.4 shows the CPT cell headings and selections for an Imagery service workflow. The imagery workflow recipe is generated similarly to the GIS workflow.
 * The MapDoc selection is replaced by an imagery dataset selection (mosaic dataset or raster dataset). *Imagery workflows will always use a RASTER image density selection.

"Best Practice: Performance adjustments are selected from look-up tables established from analysis of benchmark test results. " 

=Software technology selection=

The GIS software technology patterns were introduced in Chapter 2. The CPT Calculator can generate workflow processing loads from a variety of software technology patterns. Your CPT Software technology selection identifies the performance baseline used for generating the selected workflow processing loads.

ArcGIS Server Optimized Map Service Document (MSD)
ArcGIS 9.3.1 introduced an ArcGIS optimized map service description (MSD). The MSD replaced Windows rendering functions with an Esri developed rendering engine that improved map display quality and significantly reduced map display processing loads, improving display performance. Figure 3.5 shows the quality of some of the improved map displays produced by the MSD rendering engine.

During map service publishing, the standard map document (MXD) is translated to an optimized map service description (MSD) for high-performance, high-quality map publishing. Estimated performance gains range from 30 - 70 percent.

MSD MapDoc selection reduces SOC load in the CPT by 50 percent.
 * MSD rendering engine performs better than ArcIMS AXL and MXD-based map services.
 * Provides more consistent performance across Windows and Linux operating system environments.
 * New cartographic engine significantly improves map display output quality.

"Best Practice: Use MSD rendering for high-performance map publishing. ArcGIS 10.1 uses MSD rendering for all published map services." 


 * ArcGIS map document (MapDoc) selection

ArcGIS imagery service patterns
Figure 3.6 identifies the two imagery workflow service patterns. Imagery can be managed by using a raster catalog or with the mosaic dataset. Mosaic datasets provide significant management and image processing benefits.

ArcGIS for Server can publish a pre-processed mosaicked single image using a raster dataset or a mosaic dataset. Imagery can also be loaded into an ArcSDE Geodatabase and served directly as a single image.

"Best Practice: Mosaic dataset should be used for all imagery services. Mosaic datasets can significantly improve and simplify imagery management, and provide optimum dynamic performance from collections of raw imagery data formats. "

The mosaic dataset, introduced with ArcGIS 10, fully integrates imagery processing within the ArcGIS software.
 * The ArcGIS for Server imagery extension allows you to publish image services directly from raw imagery files using imagery processing tools associated with imagery managed by the mosaic dataset.
 * An ArcGIS for Server image service provides processing of the requested imagery extent to include dynamic mosaicking and a variety of on-the-fly imagery processing functions.


 * ArcGIS imagery selection

The selection options are MosaicDS or RasterDS. The selection choice is included in the Workflow recipe. 

Data density makes a difference
Map density has a direct impact on display compression. When using a PNG output format, solid color areas compress better than areas with rapid color change. Less display compression means more display traffic, which requires more time to deliver to the client.

Figure 3.7 shows a vector and raster output of the same map along with the different traffic and travel time for each output format. Density of the data will make a difference in processing and output image compression.
 * Results above are based on REST MXD service.
 * Both images are 600 x 400 resolutions.
 * JPEG compression works best with raster data (less traffic and faster display response time).
 * PNG compression works best with vector data (less traffic and faster display response time).

PNG24 is CPT Calculator default for vector density (vector only and VPortal).
 * Supports transparent overlay.
 * Compresses common pixel values.

"Best Practice: Use PNG8 for vector business layers when higher color depth is not required. "

JPEG is default for raster imagery density (Raster image or RPortal).
 * Common compression across different pixel values.

"Best Practice: Use JPEG output when imagery layers are included in the map display. "



CPT Calculator Density/Portal selections
Figure 3.7a shows a web service shared in a Portal workflow. Web services are registered with Portal when services are included in a Web Map shared within the Portal organization or added as a registered service. Portal registered workflows incur additional processing loads on the Portal Web server.




 * ArcGIS density/portal selection

The density selection modifies traffic and rendering time processing loads. Density selection applies to all Server workflows, and includes a heavier Web server load when services are registered with a Portal for ArcGIS service.

CPT Calculator density selections include the following:
 * Vector only
 * Raster image
 * VPortal
 * RPortal

Vector only (V) or VPortal are used when display is limited to vector feature types. Raster image (R) or RPortal are used when the display includes an imagery layer. Portal should be included in the workflow density selection when the Web service is registered with a Portal for ArcGIS Web server.



Map cache can reduce the number of dynamic display layers
Figure 3.8 shows the layered rendering process for a dynamic map service. GIS displays are created one layer at a time, similar to the procedure geographers would follow to lay out a map display on a table using mylar sheets.
 * The technology has changed, but the procedure for building a map is much the same.
 * Maps with a few layers require less processing than maps with many layers.
 * The layer complexity (number of features, edges, symbology, tasks, etc.) impacts rendering time for each layer.
 * Building a map display renders one layer at a time, joining the features (points, polygons, lines) in each layer sequentially, one on top of the other, until the final display is complete.

Parallel query displays can be published with ArcGIS for Server technology—but is the performance gain worth the use of extra shared infrastructure resources? 

For example, in Figure 3.9 a 20 layer map display is delivered to a JavaScript client over a 1.0 Mbps DSL internet connection.
 * The sequential display transaction delivers a 160 KB image to the JavaScript client in 2.16 sec. The display transaction uses 16 percent of the available network bandwidth.
 * The parallel processing transaction delivers five 96 KB images to the JavaScript client in 1.66 sec. The display transaction uses 48 percent of the available network bandwidth.

" Warning: The extra network transport time and queue time for the parallel display build consumed almost 50 percent of the parallel processing display performance gain."

"Parallel processing may not always improve display speed, and in most cases could reduce overall system performance capacity." 

Take advantage of caching (%DataCache)
Figure 1-10 shows the advantage of map caching. Map tiles are processed once to create the cache (cachingtools provide background geoprocessing service instances for creating the map cache). Client display request for cached map tiles is routed to get the requested tiles, which are then downloaded to the client for display (negligible server resources required for fetching the tiles). Once downloaded to the map display, the tiles are cached in the client browser. The second request for the tile comes from browser cache (not from the server). Tiles can also be cached at locations between the server and browser cache, and a copy of the closest available tile is delivered to the client. ArcGIS Online uses a third party caching solution to distribute cached basemap tiles at global locations throughout the internet, providing a very scalable tile delivery configuration where a majority of tile requests are serviced before reaching the GIS Server location. The location of the requested map cache tiles is the primary factor contributing to cached map display response time.

ArcGIS for Server provides a variety of ways to maintain and support pre-processed maps, and to organize the map files in a map cache structure optimized for map publishing.

A map cache reduces the number of dynamic display layers (less processing load).

Preprocessed basemap images are available in optimized map cache format.
 * Maps can include dynamic and cached layers.
 * Operational layers generated from a dynamic data source.
 * Basemaps delivered from a preprocessed map cache (static layers).
 * Client display combines operational layer rendered over cached basemap (mash-up/overlay).
 * Cached basemaps are available from ArcGIS Online.

Data classification is application-specific.
 * Dynamic layers provide the best choice for most rapidly changing data. Examples include roads showing snow depth or electrical network showing latest posted work orders.
 * Static layers provide the best choice for slowly changing data. Examples include land use/land cover, road networks, and basemap data.

The quality of the fully cached map can be much higher than the medium dynamic display (and map publishing performance still the same), the difference is that the fully cached map processing was completed before posting on the website, and the final processing time for the cached map tiles is minimal.

Best Practice: The optimum web mapping display combines dynamic map services presented as a transparent image [mash-up (business layers)] over a map cache base layer.
 * Dynamic map services are important for geographic analysis, editing, and geoprocessing functions, which require access to point, polygon, and line features rendered in a dynamic map display.
 * Map cache tiles provide an optimum basemap foundation layer, combining high-quality map visualization with high display performance.
 * A mash-up of dynamic operational layers over high-quality base map reference layer delivers the optimum combination of quality and performance. 

ArcGIS Online Basemaps
ArcGIS Online shares basemaps and reference layers freely available to anyone with Internet access. Published basemap services include World Imagery, World Street Map, World Topographic, Ocean Basemap, and more. Data appliance for ArcGIS is an Esri product designed and optimized for use with ArcGIS for Server to deliver secure mapping applications behind an organization's firewall. 

The map cache setting identifies the percentage of display layers that will be pre-processed into a tiled map cache. The percent dynamic is calculated (1-%DataCache) and the %Dyn percentage is included in the Workflow recipe.
 * ArcGIS percent data cache (%DataCache) selection

Display complexity
Display complexity is an estimate of how much processing a computer system must do to complete a unit of work. Workflow display complexity includes a broad range of software and data design factors. The complexity determination used for initial capacity planning is often a rough estimate related to a standard (medium complexity) baseline workflow processing load profile. There will be opportunities to measure the display complexity during initial publishing and deployment of the map service. 

Tradeoff between map display quality and user performance
Figure 3.11 shares the tradeoff between quality and speed when publishing a dynamic map service. The functions and analysis included in the map will impact display performance. Higher quality maps require more dynamic processing, while simple maps can be rendered much faster.

Both high-quality and simple maps can provide very similar information, but may show very different performance.
 * High-quality maps often include heavy functions such as shaded relief, transparent layers, and dynamic Maplex labeling which results in slow performance.
 * Simple maps do not require heavy functions, and the example shows low-resolution relief, solid colors, and simple annotation which enables fast display performance.

"Best Practice: High-quality map features served as a cached basemap perform very well. " 

GIS user performance expectations
Figure 3.12 shows how user performance expectations have changed along with the technology. GIS project efforts can be completed in less than half the time it took just 10 years ago. GIS professionals used to wait on computers to do their work – today computers are waiting for users to review and provide feedback.

User display performance expectations in 2003 were around five seconds—a challenge for medium map displays viewed in the computer room. The same map service today can be rendered in less than 0.25 seconds. These performance improvements open opportunities for:
 * More complex dynamic map services.
 * Deployment of ArcGIS for Server on easier-to-manage virtual server environments.
 * Deployment of web services on a hosted cloud computing environment.
 * The possibility of much richer dynamic services that employ more sophisticated statistical analysis or network routing algorithms (two to three times the complexity of current GIS workflow baselines).

These opportunities will introduce new challenges. As heavier processing options are introduced, it will be increasingly important to plan, set performance milestones, and manage compliance during system deployment.

At the same time, there are more opportunities than ever before to reduce the risk of deploying systems that do not meet your performance needs. 

Map display complexity
GIS provides users with a geographic view of their business environment, and for many GIS workflows, the map display is used as a primary spatial information resource.

" Warning: Not all map displays are created equal. " 


 * Display complexity selection

Display complexity is used to establish workflow performance targets; selection identifies the display processing load relative to a medium complexity baseline workflow.

High performance GIS mapping services
Figure 3.13 shows the display performance of five different GIS workflows. Software technology selection establishes how the workflow processing loads are distributed across the software components. The complexity selection provides your estimate of the intensity of the processing loads. This complexity estimate considers hundreds of factors that are often observable in the map display.

The first step in publishing a map service is to create a map document representing the geographic information product you wish to publish. The number of layers in the display, the number of features in each layer, and the types of processing functions required to render the map display will contribute to display complexity.
 * The software functions used to generate map documents can represent the heaviest processing loads within the user workflow. Other functions used in the analysis besides what is required to produce the display should also be considered.
 * The types of functions, data source format, and design of the user display can make a big difference on the level of processing and network loads required to support a GIS user workflow.

The CPT Calculator provides seven choices for complexity.
 * Light: Fifty percent of the loads of a medium workflow. Use for very simple map displays with a minimum number of focused layers and no heavy functions.
 * Medium-light: Processing load between light and medium complexity.
 * Medium: Standard workflow baseline, suitable for most dynamic mapping workflows that follow standard best practices for high-performance mapping.
 * Medium-heavy: Processing load between medium and heavy complexity.
 * Heavy: Heavy functions, large number of display layers, or large number of features require heavier processing loads for this workflow. Fifty percent more loads than a medium workflow.
 * 2xMedium: Twice the loads of a medium workflow.
 * 3xMedium: Three times the loads of a medium workflow.

The complexity of the authored map document will be a primary factor in determining map service performance and scalability. Light maps are rendered three times faster than heavy maps, and six times faster than the much heavier 3x Medium complexity maps.

The following are some best practices for authoring high-performance web maps. Use these recommendations as a guide to build a map that will perform within your performance budgets.

Only show relevant data.
 * Start simple.
 * Use field visibility.

Use scale dependencies.
 * Display appropriate data for the given scale.
 * Display the same number of features at all scales.

Select the appropriate point representation.
 * Use single-layer simple or character markers.
 * Use EMF instead of bitmaps.
 * Use integer fields for symbol values.
 * Avoid halos, complex shapes, and masking.

Select the appropriate lines and polygons.
 * Use the ESRI Optimized style.
 * Avoid cartographic lines and polygon outlines.

Use appropriate text and labeling. 
 * Use annotation instead of labels.
 * Use indexed fields.
 * Use label and feature conflict weights sparingly.
 * Avoid special effects (fill patterns, halos, callouts, backgrounds).
 * Avoid very large text size (60+ pts).
 * Avoid Maplex for dynamic labeling (avoid over-use).

High performance Imagery services
Similar display complexity performance variations apply to imagery workflows. Following are some best practices for authoring high-performance imagery products, in order to keep the image service time within performance budgets.

Image parameters:
 * Limit the maximum image size per request.
 * Limit the maximum number of rasters per mosaic.
 * Select the optimum resampling method.
 * Discrete data (Nearest Neighbor or Majority)
 * Continuous data (Bilinear Interpolation or Cubic Convolution)
 * Use the optimum compression method.
 * Set the optimum compression quality.
 * Set the optimum mosaic method.

Catalog parameters:
 * Limit the maximum number of records returned per request (mosaic dataset only).
 * Select the appropriate metadata level.
 * Basic, full, or none
 * Set the appropriate allowed fields (mosaic dataset only).

Download parameters:
 * Select appropriate output and virtual directories.
 * Identify supported image return type.

"Best Practice: Use the map publishing analysis tool to identify potential performance tuning opportunities. Warnings identify opportunities for performance tuning and show help documentation for adjusting complexity of your map service. " <br style="clear: both" />

Defining display complexity
Display complexity is an estimate of the average amount of computer processing required to produce an average display. For GIS mapping workflows, most of the display rendering time is consumed in creating the dynamic map product. Figure 3.14 provides an engineering chart that shows typical MSD preview rendering times for light, medium, and heavy map displays as a function of the host platform.
 * Medium map display rendering time with a high-performance 2013 platform (Xeon E5-1620 3600 MHz processors) would be about 0.152 sec.
 * The same map display rendering time measured on a 2008 Core 2 Duo T7700 workstation would be about 0.56 sec.

Rendering time is a function of display complexity and platform performance.
 * Platform performance is represented by vendor-published platform SPEC benchmark results.
 * Faster computer platforms will render the map in much less time than slower platforms.

"Best Practice: Measure display performance during map publishing to verify within design performance targets. Dynamic map display results shown in the chart were rendered from a local file geodatabase data source using the ArcGIS for Server Service editor preview tool. "

"Warning: Display complexity is a relative term representing a variety of system performance variables. Workflow display complexity is important for capacity planning since it directly contributes to system performance and scalability. "

ArcGIS for Desktop provides a map publishing Service Editor with specific performance tuning tools. Since ArcGIS 10.1, the Analyze and Preview tools appear at the top of the Service Editor only during the map publishing process.

[Map service publishing tools] are described in the ArcGIS 10.2 online documentation available on the ArcGIS Resource Center. <br style="clear: both" />

Use map publishing tools to measure display complexity
ArcGIS for Desktop provides a map publishing Service Editor with specific performance tuning tools. Starting with ArcGIS 10.1, the Analyze and Preview tools appear at the top of the Service Editor only during the map publishing process. Figure 3.15 shows the Service Editor toolbar during the map publishing process.

Steps to create a high performance map.

1. Design and create a map document in ArcMap.

2. Analyze your ArcMap document by clicking Analyze on the map publishing Service Editor.

The Analyze function will identify error messages, warning messages, and information messages.
 * Error messages identify issues you must fix before publishing the map.
 * Warning messages identify issues that may affect drawing performance and appearance.
 * Information messages identify additional considerations for performance tuning.

ArcGIS 10.2 help [Prepare window messages warnings] section includes a long list of potential performance problems. This list of error, warning, and information messages can be used for map document tuning.

3. Preview will let you zoom and pan around your map to check performance. <br style="clear: both" />

Figure 3.17 shows the map render time provided by the [ArcGIS 10.2 map publishing preview tool].
 * Rendering performance is provided at the top of the display.
 * Set the planning image output format for your service.
 * Adjust the preview display image size to match the average client display resolution.
 * Move around the more dense areas to measure display complexity.
 * Review display performance at each scale to provide a consistent user experience.
 * If performance is not acceptable, review the Analyze function warnings for additional opportunities to improve performance.

"Best Practice: Use the map publishing tools during the authoring phase to evaluate map display complexity. Render time targets can be established to author a published service within your performance budget. Early performance validation can reduce implementation risk. " <br style="clear: both" />

Use MXDPerfStat to measure display complexity
The [MXDperfstat tool] identifies display refresh times at multiple scales, shows layer refresh times for each map scale, and provides layer performance statistics [such as number of features, vectors, labeling, and breaks out display time for several key rendering phases (geography, graphics, cursor, and database)].

Figure 3.18 shows some sample MXDPerfstat results run on a file geodatabase dataset. Results are summarized for display purposes.

"Best Practice: Caching the basemap would reduce display complexity by 50 percent. "

MXDperfstat is an excellent tool for measuring map document display performance, since it lists layer statistics (render time, features, edges, projection, etc.) for each layer included within a complete series of map scales. The measured results can be used for evaluating map display complexity and tuning your map document for optimum display performance.

"Best Practice: Measure display render performance during initial map authoring to validate compliance with design performance targets. "

Once you see the layer processing time and the performance metrics, the layers with display problems are usually easy to spot. <br style="clear: both" />

Selecting the best map resolution
The resolution of the map display output can be an important consideration for GIS user workflows. A high-resolution display with full-screen map size is important for users who work with map displays over long periods throughout the day. A display resolution of 1280 x 1024 or higher may be common for GIS power users or data maintenance (GIS editor) workflows. Rich Internet applications (Flex and Silverlight) may also present higher resolution map displays.

Figure 3.19 shows the variation in traffic and response time for a 600x400 and 1280x1024 pixel display resolution of the same map. Remote client performance with a 1280 x 1024 display on a dedicated T-1 connection would be over 6 times slower than a local user display. A display resolution of 600 x 400 is a common size for web browser map displays. Remote display performance over T-1 line is less than 10 seconds.

Web mapping services produce map images that are sent to the client browser for display. Each user request will generate a new map image that must be delivered to the client browser. The size of the output image varies directly with the number of pixels, so higher resolution images generate much higher client traffic loads.

"Warning: The required amount of traffic per display can have a significant impact on user performance over lower bandwidth. "

"Note: Server processing loads may also increase with higher resolution displays (higher resolution can result in larger map extent, increasing the number of features rendered for each client display)." <br style="clear: both" />


 * Resolution selection

Calculator resolution selection identifies the map output display size. More traffic is required when publishing larger map resolution.

Selecting the best output format
Web mapping services produce map images or features that are sent to the client browser for display. Figure 3.20 shows the variation in traffic and display processing time adjustments for the different output formats. <br style="clear: both" />
 * With image services, each user request will generate a new map image that must be delivered to the client browser.
 * The selected image type can have a direct impact on the volume of network traffic. Lighter images require less display traffic and heavier images require more display traffic.
 * The required amount of traffic per display can have a significant impact on user performance over lower bandwidth.

Image output selection observations:
 * Vector-only images compress better than images that include a Digital Ortho raster layer.
 * JPEG image types provide the most consistent compression, with minimum variation between raster and vector images.
 * PNG images compress much better with vector data than with raster—PNG supports transparencies and is the default ArcGIS for Server output format.
 * PDF is a heavier output format used for high-quality map plotting.

"Best Practice: Select the data format that provides the best display performance while meeting your business requirements. " <br style="clear: both" />

Several output service formats are available for map publishing. Select the format that applies to your published service. Calculator will use the output look-up table to adjust traffic and loads based on your selection.
 * Output selection

=Data source selection=

Data source is selected for each user workflow on both the CPT Calculator and the CPT Design tabs. Data source selection is configured separate from the workflow service times, so a defined project or standard workflow can be used to create multiple use cases on the CPT Design tab each with a different data source. On the CPT Design tab, each workflow selection (row) in the requirements module will have a defined data source.

Selecting the best vector data source format
Figure 3.21 shows the application service time and traffic adjustments used by the CPT to adjust for vector data source selection. How you store and manage your data makes a difference in performance.
 * Maintenance SDE geodatabase is needed for data integrity (some performance overhead).
 * Simple feature SDE geodatabase provides improved performance for production database.
 * A file geodatabase performs well in a static, read-only environment.
 * Larger shapefile data formats incur increased traffic and performance overhead.

"Note: Data source management and deployment options will be discussed in more detail in Lesson 5: GIS data administration." <br style="clear: both" />

Several vector data source formats are available for your selection. Calculator will use a look-up table to adjust output traffic and loads based on your data format selection.
 * Vector storage format selection

Selecting the best imagery storage format
Figure 3.22 shows the application service time and traffic adjustments used by the CPT to adjust for imagery data source format selections. How you store your imagery makes a difference in performance.
 * TIFF uncompressed provides the best performance, but requires high storage traffic.
 * TIFF LZW compression results in reasonable performance overhead with high storage traffic.
 * TIFF JPEG compression results in good storage traffic reduction with reasonable performance overhead.
 * JPEG 2000 provides good storage traffic compression but incurs high performance overhead.
 * LizardTech MrSID compression reduces storage traffic with moderate performance overhead.
 * Intergraph ECW format reduces storage traffic with moderate performance overhead.
 * ERDAS IMG format requires moderate performance overhead and high storage traffic.
 * Storing imagery in an SDE geodatabase reduces storage traffic and provides good performance. This format is read-only, and is no longer a preferred Imagery storage option.

There are many factors that drive how you may store your imagery. The CPT provides a limited sample of storage options, and performance metrics can change with each software release. Performance data provided is based on preliminary test results. Much better information on performance of ArcGIS for Server Image Services should be available as the ArcGIS technology matures. <br style="clear: both" />

Several imagery data source formats are available for your selection. Calculator will use a look-up table to adjust output traffic and loads based on your data format selection.
 * Imagery storage format selection

=Custom workflow processing loads=

Custom workflow performance loads are generated from baseline workflows. Selected software performance factors are applied to generate custom baseline service times. CPT Calculator workflows are generated from performance benchmark baselines.

Custom workflow service times created on the Calculator tab are copied to CPT Workflow tab. Workflow service times can then be copied and included in Project Workflows. Calculator workflows provide a source for both standard and custom workflow performance targets.

"Best Practice: Software technology baseline service time, traffic loads, and relative performance adjustments are derived from test benchmarks. "

Standard workflows are included on the CPT Workflow tab. You can select Standard Workflows on the Calculator tab for single workflow sizing.
 * Standard workflow selections

<br style="clear: both" />

=Software performance summary=

Experience suggests we can do a better job selecting and building better software solutions. Understanding software performance can reduce implementation risk and save customer time and money. Projects can be delivered within project cost, time, and performance budgets. <br style="clear: both" />

=CPT Capacity Planning videos=


 * This video shows how to create custom workflows on the CPT Calculator tab and then move these workflows to your Project Workflow section on the Workflow tab for use in your design.

The next section will take a closer look at ArcGIS Server software performance.

=Previous Editions= Software Performance 33rd Edition Software Performance 32nd Edition Software Performance 31st Edition Software Performance 30th Edition Software Performance 29th Edition Software Performance 28th Edition Software Performance 27th Edition

Page Footer Specific license terms for this content System Design Strategies 26th edition - An Esri ® Technical Reference Document • 2009 (final PDF release)