Map Display Performance

GIS provides users with a geographic view of their business environment, and for many GIS workflows the map display is used as a common user information resource. The software procedures and functions required to generate the user map display in many cases represents the heavies processing loads required within the user workflow. The map data resources are often shared across a network from a common geodatabase data source, generating a relatively high network traffic and server processing load with each display. The map displays are simple to understand, so often the average user productivity may include up to 10 displays per minute for an active GIS power user. The types of functions, data sources, 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.

System Design Strategies 8 Software Performance C11144-12

Figure 8-1 shows the processing performance for three different ArcGIS Server dynamic map displays, all deployed on the same platform environment. The performance difference can be traced back to the complexity of the Web application map display document.

Figure 8-1

Optimum Display will make a Difference

The Web light display is generated in less than 0.5 seconds. The Web medium display requires twice the amount of display processing (less than 0.1 second), and the Web heavy display requires over three times the display processing (approximately 1.4 seconds). The design and complexity of the map display can make a very big difference in system performance and scalability. Faster server platforms would result in faster map displays.

The following best practices share lessons learned in designing and tuning for high performance Web services.

An optimum display can make a big difference on performance and scalability.

• Only show relevant data – Start simple

– Use field visibility

• Use Scale Dependencies

– Appropriate data for given scale – Same number of features at all scales

• Select the right Point representation – Use single layer simple or character markers – Use EMF instead of bitmaps

– Use integer fields for symbol values – Avoid halos, complex shapes, masking

• Select the right Lines and Polygons – Use ESRI Optimized style

– Avoid cartographic lines and polygon outline

• 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)

System Design Strategies 8 Software Performance C11144-12

8.1.1 Quality vs. Speed

Figure 8-2 shows the classic tradeoff between quality and performance.

Figure 8-2

Quality versus Speed Tradeoff

The high quality map above is a shaded relief with transparent layers and dynamic Maplex labeling. These are expensive functions that require extra computer processing for each user display. In contrast, the same display on the right uses low resolution relief, solid colors, and simple annotation providing similar information with good display performance.

System Design Strategies 8 Software Performance C11144-12

8.1.2 Optimizing lines and polygons

We discussed earlier the importance of keeping the display functions simple. The ArcGIS software includes a symbol selection called ESRI Optimized to guide users to the more simple display symbols. Outlines for all fills are simple instead of cartographic lines. Picture fills are EMF-based instead of BMP-based. Figure 8-3 shows the location of the ESRI Optimized symbol selection.

Figure 8-3

ArcGIS Desktop Display Performance

Using ESRI Optimized symbols can improve display drawing performance by up to 50 percent.

System Design Strategies 8 Software Performance C11144-12

8.1.3 GIS Dynamic Map Display Process

GIS displays are normally created one layer at a time, similar to the procedure geographers would follow to layout 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 (computer programs are more sensitive about the number of layers (feature tables) in a display than about the number of features in a single layer (rows in a feature table).

Figure 8-4 shows the software procedure for building a map display, 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.

Figure 8-4 Sequential Processing

Figure 8-5 shows a software process for building the layers of a map display using a parallel processing procedure. The procedure initiates three separate display requests, each building a third of the display layers.

An additional server process then brings the three primary layers together to build the final display.

Figure 8-5 Parallel Processing

System Design Strategies 8 Software Performance C11144-12

In theory, the second approach generates the display faster. The same amount of processing is required for both methods - in fact the parallel approach requires additional procedures for establishing the parallel display request and then bringing those results back together to produce the final map display.

Hardware vendors are providing computers with an increasing number of processor core per chip, expanding the capacity of the server platforms with reducing expectations for increased performance gains per processor core. Vendors have encourages software developers to take advantage of this increased server capacity by increasing the number of concurrent processes used in generating each user display. Most heavy processing workloads today require sequential processing and a single display generation will not take advantage of multiple processor core. The actual user display performance gains for reprogramming software to take advantage of parallel processing may not be worth the extra programming effort and additional processing loads.

Figure 8-6 compares a traditional COTS map display performance with the performance of a parallel query map display, where the display layers are blended together on the client browser. These types of displays can be published with the current ArcGIS Server 9.3 technology - but is the performance gain worth the use of extra shared infrastructure resources.

Figure 8-6

Parallel Processing Performance Gains (truth or fiction)

The parallel implementation is supported by three ArcGIS Server REST API map services mashed together in a JavaScript API client browser application. Client access was over a 1.5 Mbps DSL Internet connection, requiring over 1 sec to deliver each 200 KB map image over the network connection to the client browser display. The extra network transport time and queue time to support the parallel display build consumed most of the parallel processing display performance gain. Parallel processing may not always improve system performance, and in some cases could reduce overall system performance and scalability.

System Design Strategies 8 Software Performance C11144-12

8.1.4 Establishing appropriate map display workflow service times

Standard ESRI Workflow software service times are published to provide a common reference for initial capacity planning and to help ESRI customers establish appropriate performance targets when deploying ESRI technology. These software service times represent what many customers are able to do with the ESRI core software technology.

Figure 8-7 provides an overview of the Standard ESRI Workflow software services times provided with the