Software Performance 38th Edition

Jump to: navigation, search
System Design Strategies (select here for table of contents)
System Design Strategies 38th Edition (Spring 2016)
1. System Design Process 38th Edition 2. GIS Software Technology 38th Edition 3. Software Performance 38th Edition 4. Server Software Performance 38th Edition
5. GIS Data Administration 38th Edition 6. Network Communications 38th Edition 7. GIS Product Architecture 38th Edition 8. Platform Performance 38th Edition
9. Information Security 38th Edition 10. Performance Management 38th Edition 12. City of Rome 38th Edition 11. System Implementation 38th Edition
A1. Capacity Planning Tool 38th Edition B1. Windows Memory Management 38th Edition Preface (Executive Summary) 38th Edition SDSwiki What's New 38th Edition

Spring 2016 GIS Software Performance 38th 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

Figure 3.1 The system architecture design baseline workflow represents a medium load profile distributed across the baseline software technology components.

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 generates 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 most important 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 and DBMS components. Client communicates over the network to the DBMS server.
  • ArcGIS for Desktop Citrix deployments. Software includes the terminal Client, WTS, and the DBMS components. Terminal client communicates over the network to the WTS server.
  • ArcGIS for Server deployments. Software includes the Client, Web server (Web Adaptor), SOC (GIS Server), 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 Baseline workflow loads are translated to custom workflow loads by adjusting component services times by appropriate load factors.
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 selected based on decisions you will make in publishing the map service. Performance baselines are adjusted based on the complexity of your data structure 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) translated 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 three workflow recipe formats, one for ArcGIS Desktop workflows, one for ArcGIS Server workflows, and another for Imagery workflows.

ArcGIS for Desktop workflow recipe

Figure 3.3 CPT Calculator workflow recipe for an ArcGIS 10.3 for Desktop ArcMap application with 2D graphics, Vector only (V) display, medium complexity, 100% dynamic, 1920x1080 map size (19x10 resolution), feature output, with a cached basemap (+$$).
Figure 3.3 shows the CPT cell headings and selections for an ArcGIS for Desktop workflow. The workflow recipe provides metadata identifying software application design specifications selected in the CPT Calculator Software Technology Performance Factors module.
  • The software selection identifies the appropriate workflow performance baseline.
  • The remaining recipe selections modify the performance baseline to represent the selected workflow.
Best Practice: Performance adjustments are selected from look-up tables established from analysis of benchmark test results.

ArcGIS for Server workflow recipe

Figure 3.4 CPT Calculator workflow recipe for an ArcGIS 10.3 for Server REST service with 2D graphics, Vector only level density (V), medium display complexity, 100% dynamic (no cached layers in medium complexity display), 1366x768 map size (13x7 resolution), PNG24 output format, plus mashup with a cached basemap (+$$).
Figure 3.4 shows the CPT cell headings and selections for an ArcGIS for Server workflow. The ArcGIS for Server workflow recipe is generated similarly to the GIS workflow.
  • The software selection identifies the appropriate workflow performance baseline.
  • The remaining recipe selections modify the performance baseline to represent the selected workflow.
Best Practice: Performance adjustments are selected from look-up tables established from analysis of benchmark test results.

Image service workflow recipe

Figure 3.5 CPT Calculator workflow recipe for an ArcGIS 10.3 for Server image service using the mosaic dataset (MosaicDS) for Imagery management , 2D Graphics display, raster imagery level density (R), medium display complexity (Med), 100 percent dynamic (no cached layers), 1366x768 map size (13x7 resolution), and JPEG output format.
Figure 3.5 shows the CPT cell headings and selections for an Imagery service workflow. The imagery workflow recipe is generated similarly to the GIS workflow. For an Imagery workflow, the second word in the recipe is “Imagery”.
  • 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

Figure 3.6 Software technology selection establishes baseline performance loads for generating custom workflow performance targets.

The first step in defining a CPT workflow is to select the software deployment pattern. System performance baselines are established within the Capacity Planning Tool for a broad variety of ArcGIS deployment options.

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 for Desktop (ArcMap, Pro)

Figure 3.7 ArcGIS Pro is a new application that can run side by side with ArcMap. CPT Calculator ArcGIS for Desktop workflows now include a Desktop selection for ArcMap or Pro.
Figure 3.7 CPT Calculator ArcGIS for Desktop includes options for ArcMap or ArcGIS Pro workflows.

ArcGIS Pro is a new Desktop application included with every ArcGIS for Desktop license. Professional GIS clients can use ArcGIS for Desktop ArcMap or ArcGIS Pro depending on which application works best in supporting their business workflows.

ArcGIS Pro is a popular new ArcGIS for Desktop application with the following attractive features.

  • Provides a modern ribbon menu interface
  • Supports multiple map layouts
  • Designed with a Web GIS focus
  • Runs side by side with ArcMap
  • Provides multi-threaded display performance
  • Built as a 64-bit Windows application
ArcGIS for Desktop (Desktop) selection The selection options are ArcMap or Pro. The selection choice is included in the ArcGIS for Desktop Workflow recipe.

Graphics 2D/3D performance

Figure 3.8 ArcGIS 3D display environments are becoming more common for many business workflows. Many 2D map displays are expanding to incorporate dynamic 3D operations.
Figure 3.8 shows the new display graphics options (2D, 3D) available in the CPT Calculator workflow configurations. Dynamic 3D editing and dynamic 3D display operations are incorporated in the ArcGIS Pro application. Additional 3D display capabilities are being integrated into standard Web client applications. These 3D operations place increased graphics processing loads and heavier display traffic demands on GIS user workflow operations.

ArcGIS Pro applications take full advantage of new graphic processing unit (GPU) capabilities (selected video card becomes much more important for display performance). When deploying ArcGIS Pro in centralized virtual application/desktop server environments the server video card may be the primary capacity limitation when configuring your server environment. Dynamic 3D environments can also be much more compute intensive than traditional 2D environments, both in terms of the complexity of the data model (number of features per layer) and the application 3D dynamic processing requirements. Dynamic 3D display environments is where technology is moving – although initial operations may challenge existing server processing and network traffic capacity limitations.

Data density makes a difference

Figure 3.9 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.9 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 2D service.
  • Both images are 1366x768 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.

Figure 3.10 Registered Portal Workflow. ArcGIS for Server workflows can be registered with Portal for content management and collaboration.
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.

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 Classic dynamic mapping trade-off.
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 User performance expectations have changed over the last 10 years primarily due to faster hardware processing technology. Heavier processing loads can now be supported without impacting user productivity.
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.3 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 GIS (vector) workflow display complexity. Intensity of the workflow processing loads will depend on the display complexity.
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. The following blog posted by David Johnson from the Esri Prototype Lab Sales Support team shares recommendations for Designing and Optimizing Image Services for High-Performance Analysis. 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.

Defining display complexity

Figure 3.14 Display complexity is defined by the processing time required to render a map display from a local file geodatabase. Measured time can be normalized by adjusting for relative processor performance.
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 2014 platform (Xeon E5-1620 3600 MHz processors) would be about 0.202 sec.
  • The same map display rendering time measured on a 2008 Core 2 Duo T7700 workstation would be over 0.8 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.3 online documentation available on the ArcGIS Resource Center.

Use map publishing tools to measure display complexity

ArcGIS for Desktop provides a map publishing Service Editor with two very important performance tuning tools. Starting with ArcGIS 10.1, the Analyze and Preview tools appear at the top of the Service Editor during the map publishing process. The following demonstration shows how to use the ArcGIS for Desktop publishing analysis and preview tools for managing map display complexity.

Map service publishing tools service editor demonstration

The warnings identified by the map publishing analyze function provide opportunities for performance tuning. 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 Warning Messages 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.

The Preview tool can be used to measure display complexity. The tool identifies the map rendering time output for the current map display. The map render time is 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.

Use MXDPerfStat to measure display complexity

Figure 3.15 MXDPerfstat is an ArcScript that measures render performance for a defined map extent. Results show render time for map layers at a range of scales at a select geographic location.
The [MXDperfstat tool] identifies display refresh times at multiple scales, shows layer refresh times for each map scale, identifies data sources for individual layers, 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.14 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.

Map cache can reduce the number of dynamic display layers

Figure 3.16 Map displays are created one layer at a time. Parallel service requests can improve render performance, but will increase network traffic and may not improve user productivity.
Figure 3.16 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?

Take advantage of caching (%DataCache)

Figure 3.17 There are clear performance advantages when using a pre-processed tiled map cache for your basemap layers.
Figure 1-17 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.

ArcGIS percent data cache (%DataCache) selection

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.

Selecting the best map resolution

Figure 3.18 Selecting the right image 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 1920x1080 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.18 shows the variation in traffic and response time for a 600x400 and 1366x768 pixel display resolution of the same map. Remote client performance with a 1366x768 display on a dedicated T-1 connection would be over 3 times slower than a local user display. A display resolution of 600x400 is a common size for imbedded web browser map displays. Remote display performance over a 56Kbps line with a small map 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).

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

Figure 3.19 Selecting the right output format.
Web mapping services produce map images or features that are sent to the client browser for display. Figure 3.19 shows the variation in traffic and display processing time adjustments for the different output formats.
  • 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.

Output selection

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.

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.20 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.
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.

Vector storage format selection

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.

Selecting the best imagery storage format

Figure 3.21 CPT Imagery storage formats.

Figure 3.21 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.

Imagery storage format selection

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.

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 workflow selections

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

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.

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

Previous Editions

Software Performance 37th Edition
Software Performance 36th Edition
Software Performance 35th Edition
Software Performance 34th Edition
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

System Design Strategies (select here for table of contents)
System Design Strategies 38th Edition (Spring 2016)
1. System Design Process 38th Edition 2. GIS Software Technology 38th Edition 3. Software Performance 38th Edition 4. Server Software Performance 38th Edition
5. GIS Data Administration 38th Edition 6. Network Communications 38th Edition 7. GIS Product Architecture 38th Edition 8. Platform Performance 38th Edition
9. Information Security 38th Edition 10. Performance Management 38th Edition 12. City of Rome 38th Edition 11. System Implementation 38th Edition
A1. Capacity Planning Tool 38th Edition B1. Windows Memory Management 38th Edition Preface (Executive Summary) 38th Edition SDSwiki What's New 38th Edition

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