Server Software Performance 31st Edition

Jump to: navigation, search
System Design Strategies
System Design Strategies 31st Edition (Fall 2012)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool A2. ESD Planning tools A3. Acronyms and Glossary

Fall 2012 GIS Server Software Performance 31st Edition

ArcGIS for Server performance and capacity depends on a proper service configuration. Once you have a basic understanding of software performance, you are ready to better understand how to properly configure services for optimum server utilization.

The previous chapter on software performance introduced the concepts required to recognize the key components of the software and data that contribute to system performance. This chapter looks more closely at the specific decisions map service authors and system administrations must make in properly configuring services for optimum capacity and throughput.

ArcGIS for Server platform selection and licensing assumes you understand how to select the proper service configurations for optimum throughput and performance. Selecting the proper hardware and licensing establishes the potential for optimum system performance; proper service configuration is essential to realize this potential. This chapter provides you with the guidelines and best practices you need to achieve optimum performance from your ArcGIS for Server system deployment.

After this chapter, you will be ready to explore how network communications, platform architecture, and server platform selection complete the system design components required for implementation success.

ArcGIS for Server is changing

Figure 4-1 ArcGIS for Server. ArcGIS 10 Web, SOM, and SOC components will be consolidated into a GIS Server in ArcGIS 10.1 for Server.

Figure 4-1 shows the fundamental server architecture changes your will experience as you move to ArcGIS 10.1. The new ArcGIS for Server architecture changes were made to make Server much easier to deploy and manage in an adaptive virtualized server environment.

  • ArcGIS 10.1 for Server is a much simpler install.
  • ArcGIS Server 10 web, SOM, and SOC components are consolidated into ArcGIS 10.1 for Server GIS Server.
  • New Web Adaptor provides site-aware proxy services and network traffic load balancing.

A new product naming convention is introduced with the ArcGIS 10.1 release bringing ArcGIS together as a single integrated product line supporting a variety of deployment options.

  • ArcGIS Server 10 changes to ArcGIS 10.1 for Server.
  • Similar name changes across the ArcGIS product line.

Performance improvement summaries for ArcGIS for Server 10.1 were shared at the Esri International User Conference Technical Workshop on ArcGIS for Server Performance and Scalability - Optimizing GIS Services presented July 26, 1012. Test results show ArcGIS for Server 10.1 performing roughly the same on both Windows and Unix operating systems.

Note: Further discussion on ArcGIS 10.1 architecture changes is provided in Chapter 7: GIS product architecture.

ArcGIS Server Terminology

Figure 4-2 ArcGIS for Server includes instances, processes, and threads. Understanding this terminology is important in properly configuring the server.
What are server instances, processes, and threads?
How does this terminology change with ArcGIS 10.1?

Instances, processes, and threads identify what software will be deployed to leverage the available hardware processing resources. Figure 4-2 shows the instances, processes and threads within the ArcGIS for Server configuration.

Install instances

An ArcGIS 10 install instance refers to a single ArcGIS for Server install managed by a SOM.

  • Basic, Standard, and Advanced Server licensing requirements are established by the highest level of functionality supported by the server install instance.
  • Server install instance is replaced by the GIS Server Site and Cluster in ArcGIS 10.1.

Server process

A server process refers to a set of installed component software server executables.

  • ArcGIS 10 Server Object Manager (SOM)
  • ArcGIS 10 Server Object Container (SOC)
  • Web server
  • ArcGIS 10.1 GIS Server ArcSOC.exe processes

Process threads

The term “Process” refers to the package of program executables contained within each deployed SOC (each deployed SOC contains one copy of the ArcGIS program executables). Some server processes are multi-threaded (low isolation), and allow multiple service requests to be processed at the same time using a single copy of process executables.

  • ArcSOC.exe processes can be configured to support multiple service threads.

The term “thread” is also used at the hardware level to represent an on-chip location to park a service instance close to the core for processing (a hyper-threaded core can reduce the time required for context switching when multiple concurrent execution threads are sharing a single core processor; objective is to better utilize available core processing cycles).

Service instances

Service instance is a service configuration parameter that identifies the minimum and maximum number of process threads that will be deployed by ArcGIS for Server to satisfy inbound web service requests.

  • Minimum number of specified service instances will be deployed during server startup.
  • Additional service instances will be deployed by the service manager based on service request demands up to the maximum specified service configuration.

Service instance configuration changes with the ArcGIS 10.1 release.

Service instance configuration represents a single service request and how that request can be serviced through the software stack.

  • ArcGIS 10 Server Object Manager (SOM) would distribute the identified service instances across all assigned host machines (all machines within the ArcGIS for Server install instance). Install instance is defined by host machines assigned to a common SOM.
  • ArcGIS 10.1 for Server will deploy the identified service instances to each GIS Server machine that joins an identified cluster (each machine within the ArcGIS for Server install Site). Install Site is defined by a common (shared) Configuration Store (ConfigStore).

ArcGIS for Server process configuration

Figure 4-3 Server executables can be configured as either high isolation or low isolation processes.

Figure 4-3 shows the available ArcGIS for Server SOC process configurations. There are two types of SOC executable configurations, high isolation and low isolation (terms used by the Esri ArcGIS for Server software documentation). Process isolation settings are configured when publishing the service. Process isolation applies to both the ArcGIS 10 and ArcGIS 10.1 releases.

The isolation setting determines how the server manages the ArcSOC processes.

  • High isolation deploys single-threaded ArcSOC processes (one service instance per process).
  • Low isolation deploys multi-threaded ArcSOC processes (up to 256 service instances per process).
  • Each thread (service instance) is actually a pointer within the ArcSOC process tracking execution of the assigned service request (all requests share the same copy of the executables).
High isolation provides more stable operations.
  • Each process contains only one service instance.
  • If the service instance fails, only one process fails.
Low isolation provides more efficient instance capacity adjustments.
  • Single process start-up is required to deploy multiple service instances
  • Several service instances share the same process memory.
For example, a GIS Server deploying 12 service instances using high isolation would be launching 12 separate ArcSOC processes each providing one service instance thread. A GIS Server deploying the same 12 service instances using low isolation (4 instances per ArcSOC process) would launch 3 separate ArcSOC processes, each with four (4) service instance threads. The low-isolation SOC configuration requires less host machine memory, but if one service instance (thread) fails, the SOC process will fail along with its remaining instances. When a high-isolation service instance fails, the SOC executable failure is isolated to loss of a single service instance.
Best Practice: High isolation processes provide the most stable solution for standard mapping services.

ArcGIS Service Editor processes settings

Figure 4-4 ArcGIS for Server Processes settings are used to select low or high process isolation. Maximum number of instances is defined for low isolation settings.

Figure 4-4 shows the ArcGIS Service Editor processes settings. During the map publishing process, the author will select the SOC process isolation, identify the maximum number of instances per ArcSOC process (low isolation only), identify recycle start times, and set the keep alive connection cycles.

Select SOC isolation.

  • High isolation deploys single-threaded ArcSOC processes (one service instance per ArcSOC process)
  • Low isolation enables multi-threaded ArcSOC processes (multiple service instances per ArcSOC process)

Set maximum instances per ArcSOC process.

  • Low isolation only, can support up to 256 instances per ArcSOC process.
  • ArcSOC instances are managed by the GIS Server, based on service configuration settings.

Recycle time schedules GIS Server service instance recycle operations.

  • Cycles through and sequentially stops and restarts each ArcSOC instance.
  • Schedule during off-peak hours (batch process load sequentially restarting each instance).

Keep alive connections.

  • Checks and repairs data connections for idle instances. Set inspection schedule if you identify problems maintaining stable data connections.

Selecting a pooled or non-pooled service model

Figure 4-5 ArcGIS 10 and earlier releases support Pooled and Non-Pooled services.

Figure 4-5 identifies ArcGIS for Server ArcSOC process pooling options. Process pooling settings are configured when publishing the service. Non-pooled ArcSOC processes were required for editing workflows before the availability of the ArcGIS 10.1 feature service.

Warning: Non-pooled services are not supported with ArcGIS 10.1 for Server.

Pooled ArcSOC processes handle service requests for multiple concurrent client sessions.

  • They can be supported by low and/or high isolation ArcSOC processes.
  • They provide optimum server utilization and service throughput.

The pooled service model is the best selection for most service configurations. The current-state information (extent, layer visibility, etc.) is maintained by the Web or client browser application. The deployed service instances are shared with inbound users and released after each service transaction for another client assignment. The pooled service model scales much better than the non-pooled model because of this shared object pool.

Non-pooled ArcSOC processes handle service requests for a dedicated client session.

  • They require high isolation SOC process.
  • They support session context changes required for edit operations (prior to feature service editing).
  • Applies to ArcGIS 10 and earlier releases.

The non-pooled service model should only be used when an application’s function requires it. A non-pooled SOC is assigned to a single-user and holds its reference to the client application for the duration of the user session. In this case, the current state information (extent, layer visibility, etc.) can be maintained by the SOC process. Non-pooled SOC will not be supported beyond the ArcGIS 10 release (editing functions will be supported by pooled feature services in ArcGIS 10.1).

Best Practice: Pooled services provide the most scalable service configuration.

ArcGIS for Server pooling settings (service instance min/max settings)

Figure 4-6 ArcGIS 10.1 for Server pooling settings are used to select service configuration minimum and maximum service instance configurations.

Figure 4-6 ArcGIS Service Editor ArcGIS 10.1 pooled service instance settings. The service instance parameters are identified under Service Editor Pooling. The minimum number of instances would normally be “1” to avoid startup delays when the service is requested by a single user. If the service is seldom used, this setting could be “0”, in which case there would be a startup delay with the first service request. The maximum number of instances establishes the maximum system capacity the GIS Server can expose to this service configuration. It’s worth repeating: configuring service instances beyond the maximum platform capacity will not increase system throughput, but it may very well reduce user display performance.

Best Practice: Select pooled services for optimum performance.
  • Use non-pooled services only when needed for editing sessions.
  • ArcGIS 10.1 will support pooled feature service editing (Non-pooled services not supported)

Minimum and maximum service instance setting:

  • Establishes parameters for GIS Server service instance management.
  • Minimum service instances are deployed during GIS Server startup.
  • Maximum service instances establish limit for GIS Server service instance deployment.


  • Maximum time a client can use a service. Establishes timeout for hung service instances.
  • Maximum time a client will wait to get a service. Establishes maximum service queue time.
  • Maximum time an idle instance can be kept running. Shuts down inactive ArcSOC process.

Map Service configuration

Minimum and maximum service instances are identified when publishing a map service. It is important to identify the proper instance configuration for each map service deployment. Proper service instance configurations depend on the expected peak service demands and the server machine core processor configuration.

Web service instance configuration (concurrent users)

Figure 4-6 Web mapping service instance load profile.

The blue line in Figure 4-7 shows the maximum host platform utilization and system throughput in displays per minute (DPM) for a series of ArcGIS Server service configuration instance settings responding to random Web service requests. The bars show GIS Server machine service time (colored tier) and service queue times (processing queue times result from random arrival of service requests). The server machine has 4-core; the four core processors are shared resources used to execute the deployed service instances.

The first bar represents a service configuration with two (2) service instances. Peak service load is limited to 36 percent host platform utilization with peak throughput of 224 DPM and display response time just over 0.5 seconds, well below the maximum host platform throughput capacity. The seventh bar represents a service configuration with fourteen (14) service instances. Host platform is over 90 percent utilization with a display response time of around 1.5 seconds. Average display response time continues to increase as additional service instances are deployed with minimum increase in throughput. Peak throughput is normally reached at about 3 to 5 service instances per host platform core. Increasing the number of service instances will only increase the average display response time with minimal throughput gain.

Random arrival distribution reduces peak throughput per service instance.

  • Peaks and valleys in the arrival distribution place varying demands on server processing loads.
  • Sufficient number of instances must be available for service assignment to achieve peak throughput values.

Service configuration min/max instance settings impact server performance.

  • During light server loads, more service instances can increase server peak throughput.
  • During heavy server loads, more service instances have minimum impact on peak throughput.
  • More service instances increases display response time.

For a popular service, the maximum instances number should be large enough to take advantage of the full site capacity. Full site capacity may require 3-5 service instances per core. A site with 4-core GIS Server machines would require a maximum service instance setting of 16—the recommended instance setting for a popular map service.

Best Practice: Set map service configuration minimum and maximum instance settings to optimize site performance.

Optimum Web mapping service instance configuration.

  • Minimum instance = One, for most popular map service configurations.
    • Provides rapid service response for first user access.
    • Reserves memory and capacity space for other active map services.
    • Service instances can grow up to the maximum instance setting during peak loads.
  • Maximum instance = Three to five instances per server machine core.
    • Provides optimum throughput during peak service loads.
    • Optimizes display response time performance during peak loads.

CPT Design map service instance configuration

CPT Design tab can be used to demonstrate the optimum number of Map service instances.

Batch process service configuration

Figure 4-9 Batch process loads

The blue line in Figure 4-9 shows the maximum host platform utilization and system throughput in displays per minute (DPM) for a series of ArcGIS Server batch process service configuration instance settings. The bars show host platform service time (colored tier) and service wait times (wait times are due to shared use of the available core processor). The host platform has 4 core; the four core processors are shared resources used to execute the deployed service instances.

The first bar represents a batch process configuration with one (1) service instances. Peak service load is limited to 22 percent host platform utilization with peak throughput of 137 DPM, well below the maximum host platform throughput capacity (display service time is normally not important for batch process loads – more attention is given to how long the total batch job will run).

The fifth bar represents a service configuration with five (5) service instances. Host platform reaches 100 percent utilization with minimum increase in batch run time. Display response time (including total batch service run time) will increase linearly once server is operating at 100 percent utilization. A service configuration with ten (10) service instances would take twice as long to complete each batch job. Peak throughput is normally reached at N+1 service instances (host platform core + 1). Increasing the number of service instances will only increase batch processing times – it is better to queue up processes and complete jobs sequentially that try to run them all at the same time.

Batch process minimum and maximum instance settings are different than map services. Batch processes consume a server processor core.

  • Process queue provides consistent processing load.
  • Minimum number of service instances should be assigned to optimize processing performance.

Service configuration min/max instance setting impact server performance.

  • More service instances provide more throughput when available

instances are less than available processor cores.

  • More service instances increase batch runtime when available

instances are more than available processor cores.

Best Practice: Set map service configuration minimum and maximum instance settings to optimize site performance.

Optimum service instance configuration:

  • Minimum instance = Zero, for most batch process configurations
    • ArcSOC process start-up time is often short compared to overall batch load.
    • Reserves memory and capacity space for other active map services.
    • Service instances can grow up to the max instance setting during peak loads.
  • Maximum instance = Provide one more batch instance than available server machine cores (N+1 instances where N = number of server cores).
    • Provides optimum throughput during peak service loads.
    • Minimizes batch runtime performance during peak loads.

Many ArcGIS services perform as batch processes.

  • Most heavy geoprocessing services
  • Map caching services
  • Map printing services
  • Heavy network routing services
  • Imagery processing services

A batch process can be any service that runs for a long time without user input. Batch processes include geoprocessing, map cache generation, system backup, map production script, replication services, or any other calculation that may take longer than 60 seconds to complete without user input. This type of service should be initiated from the client application as a work request, and delivered to a queue for sequential processing by a batch process service.

Best Practice: Batch processing can be the most efficient way to handle heavy processing loads.
Warning: For handling a heavy batch service, the maximum instances should be a small number to protect site resources. A single, heavy batch service can consume a server core for the length of the service process time. Four concurrent batch requests on a 4-core server can consume all available host processing resources.

Batch process workflow can be configured in the Capacity Planning Tool by setting the workflow minimum think time = 0. Batch workflows can be used on the CPT Design tab to reserve system resources for batch processing during heavy loads. You will need to use the RESET ADJUST function to calculate productivity loads.

Design batch process instance configuration

CPT Design tab used to demonstrate the optimum number of batch process service instances.

GIS Server machine memory configuration

Figure 4-11 Configuring the server machine with sufficient physical memory is important for ensuring performance and capacity goals are met.

The platform configuration must include sufficient physical memory to accommodate all active process executions. Systems that do not have sufficient memory will experience performance degradation during peak load conditions (processing overhead increases due to operating system swapping executables between disk and memory). If memory is not sufficient to support concurrent server processing requirements, system will start to experience random process failures (process executables dropped from memory during execution). Figure 4-11 shows memory performance considerations for an ArcGIS Server host machine deployment.

Best Practice: Sufficient platform physical memory is critical to successful operations.

Active software processes must be located in physical memory for successful execution. If sufficient memory is not available:

  • Inactive processes will be swapped to memory cache to make room for active processes.
  • Active processes will crash if swapped from memory during execution.

Too many instances per server can exhaust memory.

  • Increased paging when not enough memory.
  • Slower processing due to shared compute resources.

Optimum maximum instances assignments can vary based on service popularity. A maximum of 10 instances per core is recommended for most map service scenarios.

  • Provides sufficient overhead for server instance management.
  • Avoids excessive starting and stopping ArcSOC processes during peak throughput loads.

Too few instances per server:

  • Can limit utilization of host hardware.
  • Minimum of three instances per core recommended.
Best Practice: Provide sufficient memory to support optimum performance.
  • Minimum of 3 GB memory per core recommended.
  • More memory may be required when using large file data sources (imagery).

The operating system will use extra memory for data cache, which for some workflows can improve throughput performance.

Server host platform capacity

Warning: Too many instances deployed on a single host machine can exceed available memory limits and cause an unstable service environment.
Figure 4-12 Too many service instances deployed on a single server can increase loads beyond optimum capacity and exceed available memory limits.

Figure 4-12 shows the role of host capacity setting in limiting the maximum number of deployed service instances. Customer deployments with ArcGIS 10 and earlier releases would often include a large number of map service configurations, providing focused map applications to match a variety of user needs. Multiple service configurations were one way of enabling users to manage layer selection in the client map display.

ArcGIS 10.1 provides a new dynamic layer functionality that enables client layer selection before executing the map service. This will allow customers to use a smaller number of common web applications for a broad range of user cases—reducing the maximum service instance configuration requirements for a server site.

The total number of service instances deployed on a host machine includes the sum of all service instances deployed on that host. Server host capacity settings provide a way to manage the total number of service instances assigned to a host—host capacity tells the Server Manager the total number of instances from all services it can deploy on any one machine and one time.

The host capacity setting limits the total number of server object instances running on a host machine at one time. Once host capacity numbers are reached, an ArcSOC service instance must be shut down in order to add another ArcSOC service instance.

Best Practice: Setting a host capacity protects the machine from memory overflow.

A full discussion on setting host platform capacity with ArcGIS for Server 10.0 is provided in the Software Performance chapter in the 30th Edition.

Warning: Make sure you have sufficient physical memory to handle the maximum number of active service instances that may be deployed on you GIS Server host machines.

Service configuration and optimum capacity

There are a handful of GIS Server terms and configuration strategies – there is no simple recipe for getting it right. It all depends on your user environment – how popular will your services be and how will people access your site. The overall goal is to configure GIS Server to handle the maximum number of requests with the minimum amount of processing overhead. A summary of the service configuration and optimum capacity discussion for ArcGIS 10.0 for Server, along with a nice summary diagram, is available in Chapter 4: Software Performance 30th Edition.

ArcGIS for Server has a GIS Server that manages the internal ArcSOC processes based on instructions provided with each service configuration. Services are what you publish on the GIS Server. Web applications consume these services to produce the client display. The service requests are sent to ArcSOC process threads that are executed by the hardware core processors.

Each published service will have a service description file. The service description file will contain the parameters you identify when publishing each service description. How you configure your services will determine how they will be deployed by the GIS Server. Service description files are created from ArcGIS for Desktop during the map publishing process.

There are some key things to keep in mind when publishing services. The GIS Server will deploy SOC service instances within the bounds established by the service description MIN/MAX instance settings. The minimum service instances for all services will be deployed during GIS Server startup – this establishes the minimum number of instances that will be deployed within each GIS Server machine. During peak concurrent loads, the GIS Server can increase the number of SOC instances up to the maximum service description levels if required to support concurrent inbound service requests.

Keep in mind, there is extra platform processing overhead required every time the GIS Server has to start a new SOC process. Ideally, you would like to deploy just the right amount of service instances so there is one available for immediate GIS Server assignment for each client request. During peak server loads, you want to have just the right number of maximum service instances identified to fully utilize available host platform compute resources staying well within available platform memory limitations. During maximum peak loads, you want to limit concurrent processing loads to allow optimum service throughput. For high performance services (processing time less than 1 second) you may want to allow two or three times the number of instances required for peak system throughput.

During installation, GIS Server is installed on each host machine. This provides the ArcGIS code needed to support SOC deployment. During startup, the GIS Server deploys the minimum number of service instances for each service description within each GIS Server machine. Service instances are deployed in SOC processes.

During operations, if concurrent requests for a specific service exceed the number of deployed service instances, the GIS Server will increase the number of deployed service instances to handle peak request rates up to the maximum value allowed for in the service description. If the inbound concurrent requests for that service exceed the maximum deployed instances you’ve set in the service description, requests will wait in the service queue until an existing service instance is available for service assignment Non-active services can be reduced down to the minimum instances specified in their service description file based on their service instance timeout settings.

Deployment algorithms within the GIS Server provide even distribution of service instances across the assigned host platforms. The deployment algorithms along with the service queue work to balance the GIS Server processing load across machines assigned to the same GIS Server Site. The GIS Server will be used as the final load balance solution for the machines within the GIS Server site.

Understanding what each of these performance parameters do and how they should be configured to satisfy your specific service needs is important for optimum utilization of your host servers. Getting this right will take some thinking and some careful planning. Once you deploy your services, you will need to monitor to see if your settings are working. Modifications can be applied to optimize your specific service loads. Remember, the goal is to configure the system to minimize processing overhead (excessive SOC process startup during peak service loads is overhead you would like to avoid). Also, a sufficient number of service instances must be deployed to consume available host platform compute resources and enable the host platform to service peak throughput loads.

Cached map service

Figure 4-13 Cached datasets provide multiple scales of tiled images for use as a preprocessed map service. Cache structure includes four times the number of tiles for each doubling of the scale resolution.

ArcGIS Server provides a pre-processed map cache service for use as a data source for Web applications and ArcGIS for Desktop or custom desktop clients developed with the ArcGIS Engine or ArcGIS Runtime. ArcGIS for Server can also stream pre-processed map cache images to ArcGIS Engine and ArcGIS for Desktop with 3D Analysis client for 3D visualization. In both cases, once downloaded, the cached images are stored at the client for high performance display. ArcGIS supports on-the-fly translation of 2D map cache to 3D images with both map cache and cached Imagery base maps. Figure 4-13 provides an overview of the cached map service image structure. ArcGIS for Server includes automated processing functions to build and maintain (pre-process) optimized map cache pyramids.

Best Practice: Cached tiles enable a highly scalable static map service.

The cached map service would consist of a pyramid of pre-processed data imagery or vector data, starting at a single map resolution at the highest layer and breaking each image into four images at twice the map scale for each additional layer included in the pyramid.

Tiles are pre-rendered at fixed scales.

  • Use common ArcGIS Online, Google, and ArcGIS Online world map scales for optimum data integration and mash-up performance.

Rapid display of static base maps.

  • Use the map cache to serve static basemap layers for the best display performance.

Richer symbols and more information available with high-capacity publishing capability.

  • Create high-quality basemaps. High-quality map cache tiles display as fast as simple tiles.

Estimated map cache generation time

Figure 4-14 Engineering chart for estimating cache generation time. Processing time grows exponentially with each additional layer of cache tile generation.

Client access to the cached data would deliver tiles that correspond to the requested map scale. Tiles would be blended together as a single reference layer by the client application. Total pre-processing time would depend on the total number of tiles in the map cache and the average map service time for rendering each map tile image. Figure 4-14 can be used to get a rough estimate of the expected map cache generate time.

Map cache generation time is a function of the number of tiles and average tile generation time.

  • Chart shows one tile at the top layer.
  • The number of tiles increases by a factor of four with each additional layer.
  • Tile render time can vary from less than one second to several seconds, depending on the average tile map complexity.

Rendering time increases exponentially with each tile layer.

  • Generation time: Nine hours for seven layers
  • Generation time: 40 hours for eight layers

Estimating map cache generation time.

  • Build a small area to test the output symbology, labeling, and performance criteria for your primary map client.
  • Execute cache jobs in sections to manage production time.
Warning: The caching process can be time consuming.

Map cache generation service configuration

Figure 4-15 Map caching is now a part of ArcGIS for Desktop, and included in the Service Editor during the map publishing process.

Figure 4-15 shows a view of the ArcGIS 10.1 Service Editor Caching settings. A SampleWorldCities dataset is selected and the display shows the suggested tiling scheme. A tool is included that calculates an estimate of the cache size. You can chose to have the cache start automatically once you complete the configuration, or save the configuration and start the caching job manually at a later time.

Figure 4-16 The pooling service settings are included within the Service Editor when publishing a map caching service.

Figure 4-16 shows the Pooling settings for the CachingTools service. The recommended service instance setting for caching services is N+1 (number of available core on the server machine plus one). Maximum setting of 3 service instances would be appropriate for 2-core GIS Server machines.

Timeout setting should be appropriate to the caching service.

  • Maximum time a client can use a service = 3000000 seconds (time to complete the caching job).
  • Maximum time a client can wait to use a service = 60 seconds (this assumes you have not caching jobs in the queue, you may need to increase this value if you have additional caching jobs waiting for processing.
  • Maximum time an idle instance can be kept running = 180 seconds (this can be a short time, allowing instances to be shut down if not in use).

Figure 4-17 The Windows Task Manager can be used to confirm full server capacity is being utilized during the caching process.

If you have the service instances configured properly, you should be able to take full advantage of the available hardware processing capabilities. Figure 4-17 shows a window task manager for a 4 core workstation working running batch jobs at full capacity. CPU usage should peak at 100 percent when running with N+1 service instances.

Warning: ArcGIS 10.1 for Server GIS Servers are cluster-aware, and common service instance configurations apply for each GIS server machine within a site cluster. If you establish a maximum service configuration of 5 instances, then 5 service instances will be deployed for each of the GIS Server machines within the Site.
Note: This is a change from ArcGIS 10.0, where the maximum service instance configuration was distributed across the available host machines within the ArcGIS Server Install Instance.

This video on [ArcGIS 10.1 Map Caching Tutorial] provides a demo showing the new workflows and features of map caching in ArcGIS 10.1 for Server.

Figure 4-18 Caching timelines are reduced linearly based on the number of available processor core.

Figure 4-12 provides an example of taking advantage of the hardware, as described above. ArcGIS for Server will use the maximum available service instances to process the map cache as quickly as possible with the available hardware.

Cache processing timelines can be improved by increasing the number of concurrent processor cores utilized in the caching process.

Testing was performed on identical 4-core server platforms.

  • Single service instance (thread) on a single 4-core server took 500 hours.
  • Five (5) service instances (threads) on a 4-core server took 125 hours (four times faster).
  • 10 service instances on two 4-core servers took 65 hours (eight times faster).
Best Practice: Take advantage of available hardware resources

Selecting the right technology: A case study

Selecting the right software technology can make a big difference in performance and scalability, and cost of the production system. The following case study shares an experience with a real customer implementation which clearly represents the value of selecting the right software technology.

Greek citizen case study background

Figure 4-19 Greek government contacted Esri to develop a solution for their Greek National Citizen Declaration.

The customer had a requirement to design a web application solution that would be used to collect national property location and census information during a three-month national citizen declaration period. The Figure 4-19 shows the area of Greece involved in the census.

Citizens would report to local regional government centers and use a local desktop computer to locate their home residence on a map display generated from a national imagery and geospatial feature repository. The citizen would place a point on the map identifying their residence, and then fill out a reference table identifying their census information.

The citizen input would be consolidated at a centralized national data center and shared with all regional government centers throughout the declaration process.

User requirements for web mapping solution

Figure 4-20 This network diagram shows the central National Data Center and sample small and large regional centers used in completing the design.

Figure 4-20 provides an overview of the national architecture. The initial system design was developed using an earlier ArcGIS for Server web application development framework (ADF) map editor, hosting a centralized ArcGIS for Server dynamic web application with browser clients located at 60 regional national sites. Following contract award, the customer reviewed available technology options to finalize the system design.

Peak web service use requirements

  • 2400 concurrent client edit sessions.
    • 75 percent map query to find home location
    • 25 percent simple edits (select point and complete attribute table)
  • 60 remote user locations, one central national data center.
    • Large site: 50 concurrent clients
    • Small site: 10 concurrent clients

Web mapping services architecture patterns.

Figure 4-21 Four ArcGIS for Server web technology patterns were considered. They included an early Map Editor ADF application, two Adobe Flex applications, and one Windows Mobile application.

Figure 4-21 shows the ArcGIS for Server architecture patterns that were considered for the Greek citizen declaration solution.

Initial hardware proposal

The following workflow was used to generate system loads for the initial hardware proposal.

  • Web ADF application with central dynamic SDE data layers
CPT Workflow: AGS930 ADF MXD R 100%Dyn Lite 10x7 JPEG
System implementation design review (after grant approval)

After some time, the European Union approved the Greek Citizen Declaration grant based on the initial hardware proposal. The Greek cadastral team traveled to Esri to review available technology options for final implementation.

The following web mapping services architecture patterns were reviewed to identify optimum deployment scenario.

  • Web ADF application with central dynamic SDE data layers
CPT workflow: AGS10 ADF MXD R 100%Dyn Lite 10x7 JPEG
  • Web Flex application with central dynamic SDE data layers
CPT workflow: RESTdyn_Composite Workflow from the following composite recipe:
  • Basemap_AGS101 REST MSD R 90%Dyn Lite 10x7 JPEG
  • busLayer_AGS101 REST MSD R 10%Dyn Lite 10x7 Feature
  • 100 percent dynamic
  • Web FLEX application with point feature layer + central map cache
CPT Workflow: AGS101 REST MSD V 10%Dyn Lite 10x7 Feature +$$
  • Web mobile application + local map cache
CPT Workflow: AGS101 SOAP MSD V 5%Dyn Lite 10x7 Feature
Best Practice: Significant technology improvements have become available since the initial proposal. It is always good to update the final solution architecture based on current technology before final implementation.

ADF application with central dynamic SDE data layers

CPT Calculator design shows platform solution when supporting business needs using 100 percent dynamic web ADF map editor server technology.

Hardware solution:

  • 17 E5-2637 4-core (1 chip) 3000 MHz servers
  • ArcGIS for Server licensing for up to 40 cores

Total estimated technology cost of $695,000

Peak network traffic estimates

  • 10 Mbps for large sites, recommend 24 Mbps bandwidth
  • 2 Mbps for small sites, recommend 6 Mbps bandwidth
Flex application with central dynamic SDE data layers

CPT Calculator composite workflow analysis tool is used to calculate composite service times for display mash-up of dynamic business layer feature service with dynamic basemap layer map service.

Hardware solution:

  • 9 E5-2637 4-core (1 chip) 3000 MHz servers
  • ArcGIS for Server licensing for up to 24 cores

Total estimated technology cost of $390,000

Peak network traffic estimates

  • 12 Mbps for large sites, recommend 24 Mbps bandwidth
  • 2.4 Mbps for small sites, recommend 6 Mbps bandwidth

Web FLEX application with point feature layer + central map cache

ArcGIS Server provides a data cache option where reference map layers could be pre-processed and stored in a map cache pyramid file data source. Pre-processing the reference layers would significantly reduce server processing loads during production operations. A single point declaration layer contained all features that would be edited and exchanged during the citizen declaration period; all remaining reference layers could be cached. Changes would be displayed at all remote site locations with each client display refresh.

Hardware solution:

  • 3 E5-2637 4-core (1 chip) 3000 MHz servers
  • ArcGIS for Server licensing for up to 8 cores

Total estimated technology cost of $180,000

Peak network traffic estimates

  • 5 Mbps for large sites, recommend 12 Mbps bandwidth
  • 1 Mbps for small sites, recommend 3 Mbps bandwidth
Web mobile application with edit feature synchronization + local map cache

The fourth design option was to use the ArcGIS Mobile application with a local reference cache data source. A demo of the ArcGIS Mobile client was provided on a Windows desktop platform to demonstrate feasibility of supporting the required editing functions with this client technology. The ArcGIS Mobile client technology operates very well on a standard Windows display environment and performed all the functions needed to support the citizen declaration requirements.

Hardware solution:

  • 2 E5-2637 4-core (1 chip) 3000 servers
  • ArcGIS for Server licensing for up to 4 cores

Total estimated technology cost of $70,000

Peak network traffic estimates:

  • 1.25 Mbps for large sites, recommend 3 Mbps bandwidth
  • 0.25 Mbps for small sites, recommend 1.5 Mbps bandwidth

Caching advantage summary

Figure 4-27 Business analysis comparing the four software technology solutions.

It was very clear that the cached client application provided significant cost and performance benefits over the centralized Web application dynamic solution included in the initial proposal. Pre-processing of map reference layers as an optimized map cache pyramid can significantly improve display performance. Use of an intelligent desktop client that can access reference layers from a local map cache can minimize network traffic and improve display performance even more. Selecting the right technology can make a big difference in total system cost and user productivity. Figure 4-27 highlights the advantage of selecting the right technical solution.

Best Practice: Selecting the right technology solution can make a big difference in price and user performance.

Business analysis identifies clear advantages in the ArcGIS for Mobile solution.

  • Over $620,000 savings in technology cost alone.
  • Significant savings on reduced infrastructure network bandwidth requirements.

Software performance summary

Experience suggests we can do a better job configuring ArcGIS Server deployments. Proper server configurations can reduce implementation risk and save customer time and money. Projects can be delivered within project cost, time, and satisfy performance budgets.

The next section will take a closer look GIS Data Administration.

Previous Editions

Software Performance 30th Edition
Software Performance 29th Edition
Software Performance 28th Edition
Software Performance 27th Edition

System Design Strategies
System Design Strategies 31st Edition (Fall 2012)
1. System Design Process 2. GIS Software Technology 3. Software Performance 4. Server Software Performance
5. GIS Data Administration 6. Network Communications 7. GIS Product Architecture 8. Platform Performance
9. Information Security 10. Performance Management 11. System Implementation 12. City of Rome
A1. Capacity Planning Tool A2. ESD Planning tools A3. Acronyms and Glossary

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