Server Software Performance (CPT Demos) 41st Edition

Arc17CapacityPlanning0701 release

Server software performance parameters are used to allocate appropriate server resources for optimum system throughput. Selecting the proper hardware and licensing establishes available system resources; proper service configuration is essential to realize the available throughput potential. This chapter provides you with the guidelines and best practices you need to achieve optimum performance from your ArcGIS Server system deployment.

ArcGIS Server batch process instance configuration
The brown line in Figure A-4.2 shows the maximum host platform 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. 

CPT Calculator batch process instance configuration
Figure A-4.3 shows the CPT Calculator tab configured for a batch process service instance demonstration. The purpose of the demonstration is to show the optimum service instance configuration for a batch process.

CPT Calculator configuration
 * A sample WebMap workflow with an Enterprise geodatabase data source is used for demonstration purposes. When including batch processes in your enterprise design, select a workflow that approximates the load distribution of the batch process you wish to represent.
 * A single tier platform software configuration (cell A9) is used as the GIS Server, all software installed on the GIS platform tier.
 * The fixed nodes in the platform tier (cell D25) is set at 1 to restrict the platform tier to a single server during peak loads.
 * The workflow minimum user think time is set at 0 (cell D6). The CPT Calculator will treat the workflow as a batch process when the minimum think time is set to 0.  Batch process workflows can be included within an Enterprise design and will reserve the appropriate compute resources based on the batch service instance configuration.
 * Select "Batch" in cell J15 to include client loads on the application tier.
 * Batch process workflows will identify maximum productivity in cell C6.

CPT Design tab batch process instance configuration
Figure A-4.4 shows the CPT Design tab configured for a batch process service instance demonstration, using the CPT Design RESET ADJUST function to calculate batch workflow productivity. The purpose of this demonstration is to show how to include batch processing loads in the CPT Design analysis based on the configured geoprocessing service instance configuration.



CPT Design tab configuration
 * A sample WebMap workflow with an Enterprise geodatabase data source is used for demonstration purposes. When including batch processes in your enterprise design, select a workflow that approximates the load distribution of the batch process you wish to represent.
 * A single tier platform software configuration is used as the GIS Server, all software installed on the GIS platform tier.
 * The fixed nodes in the platform tier (column H) is set at 1 to restrict the platform tier to a single server during peak loads.
 * The workflow minimum user think time is set at 0 (cell T6). The CPT will treat the workflow as a batch process when the minimum think time is set to 0.  Batch process workflows can be included within an Enterprise design and will reserve the appropriate compute resources based on the batch service instance configuration.
 * Batch process workflows will calculate maximum productivity by forcing use of the RESET ADJUST function in cell T2.

"Warning: The RESET ADJUST function in Cell T2 must be used to calculate batch process productivity. "

Figure A-4.5 shows the CPT Design tab configured for a batch process service instance demonstration, using the CPT Design AutoBatch function to calculate batch workflow productivity. The purpose of this demonstration is to show how to include batch processing loads in the CPT Design analysis based on the configured geoprocessing service instance configuration.
 * CPT Design AutoBatch selection (cell D1) will calculate maximum service productivity for all batch workflows identified with min think time = 0 in column T.

"Note: AutoBatch capability must be reset to Live when using the CPT Design RESET selection (cell T2) to recover from an unstable analysis condition." 

CPT batch process pooling configuration throughput summary
The graph in Figure A-4.6 shows the maximum host platform throughput in transactions per hour (TPH) for a series of ArcGIS Server batch process service configuration instance settings. Results generated by the simple CPT Calculator model overlay results provided by the CPT Design analysis. The host platform has 4 core; the four core processors are shared resources used to execute the deployed service instances. 

CPT Design map service instance 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.

The brown line in Figure A-4.7 shows the peak host platform 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.

Figure A-4.8 shows the CPT Design tab configured for a Web mapping service instance demonstration. The purpose of the demonstration is to show the optimum service instance configuration for a defined Web mapping service.

CPT Design tab configuration
 * The sample WebMap workflow with an Enterprise geodatabase data source is used for demonstration purposes.
 * A single tier platform software configuration is used as the GIS Server, all software installed on the GIS platform tier.
 * The fixed nodes (column H) is set at 1 to restrict the platform tier to a single server during peak loads.
 * The workflow minimum user think time is set at 0.01 (cell T6). This provides a negligible delay between display transactions simulating a pooled service instance.  Any value above zero will include random arrival queue times, simulating a live Web map request arrival distribution.
 * Select "Test" in cell D1. The Test configuration will calculate maximum productivity by forcing use of the RESET ADJUST function in cell T2.

"Warning: The RESET ADJUST function in Cell T2 must be used to calculate map instance maximum productivity. " 

CPT Design Web service pooling configuration throughput summary
The graph in Figure A-4.9 shows the peak host platform throughput in transactions per hour (TPH) for a series of ArcGIS Server service configuration instance settings responding to random Web service requests. The graph shows GIS Server machine Web service peak throughput based on the service instance configuration (throughput generated from random arrival of service requests). The host platform has 4 core; the four core processors are shared resources used to execute the deployed service instances. 

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.

User requirements for web mapping solution

Figure A-4.10 shows an overview of the national architecture. The initial system design represents a 100% dynamic Web feature service, hosted by a centralized ArcGIS Server dynamic web service and imagery base maps with rich 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 A-4.11 shows the ArcGIS 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.
 * ArcGIS Server REST feature service with central dynamic SDE data layers and imagery cache.
 * CPT Workflow: AGS REST 2D V Lite 100%Dyn 13x7 Feature +$$
 * System implementation design review (after grant approval) 

After some time, the Greek Citizen Declaration grant based on the initial hardware proposal was approved. 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.
 * ArcGIS Server REST light 100 percent dynamic feature service + central hosted imagery cache.
 * CPT workflow: AGS REST 2D V Lite 100%Dyn 13x7 Feature +$$


 * ArcGIS Server REST light 10 percent dynamic feature service + central hosted base map cache.
 * CPT workflow: AGS REST 2D V Lite 10%Dyn 13x7 Feature +$$


 * Mobile application with ArcGIS Server edit feature synchronization service + local map cache.
 * CPT Workflow: AGS REST 2D V Lite 5%Dyn 13x7 Feature

"Best Practice: Technology improvements were available since the initial proposal. It is always good to update the final solution architecture based on current technology before final implementation. "

ArcGIS Server REST 100 percent dynamic feature service + central hosted imagery cache
Figure A-4.12 shows the CPT analysis for the light 100 percent dynamic ArcGIS Server REST solution. Standard Xeon E5-2637v4 4 core (1 chip) 3500 MHz servers were used for this assessment. These are high performance 2016 server platforms.

CPT Workflow: AGS REST 2D V Lite 100%Dyn 13x7 Feature +$$

Peak system requirements:
 * Estimated peak load of 2400 concurrent users
 * Simple web application with minimum layers supported by a light workflow
 * Standard output display environment

Hardware solution:
 * 4 Xeon E5-2637v4 4 core (1 chip) 3500 MHz
 * ArcGIS Enterprise licensing for up to 8 cores

"Note: High throughput for light map service results in significant communication overhead in a multiple machine ArcGIS Server Site configuration. GIS Servers are deployed in a single cluster site (siloed) configuration to reduce internal site communication loads."

Peak network traffic estimates
 * 35.85 Mbps for large sites, recommend 90 Mbps bandwidth
 * 7.17 Mbps for small sites, recommend 18 Mbps bandwidth

"Warning: Rendering 100 percent of a dynamic map display over the network can result in high traffic loads that impact performance and required bandwidth capacity."

ArcGIS Server REST light 10 percent dynamic feature service + central hosted base 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.

Figure A-4.13 shows the CPT Calculator analysis for the ArcGIS Server light 10 percent dynamic feature service with a cached basemap. Standard Xeon E5-2637v4 4 core (1 chip) 3500 MHz servers were used for this assessment.

CPT Workflow: AGS REST 2D V Lite 10%Dyn 13x7 Feature +$$

Peak system requirements:
 * Estimated peak load of 2400 concurrent users
 * Simple web application with minimum layers supported by a light workflow
 * Standard output display environment

Hardware solution:
 * 2 Xeon E5-2637v4 4 core (1 chip) 3500 MHz servers
 * ArcGIS Enterprise licensing for up to 4 cores

Peak network traffic estimates 
 * 5.85 Mbps for large sites, recommend 12 Mbps bandwidth
 * 1.17 Mbps for small sites, recommend 3 Mbps bandwidth

Web mobile application with edit feature synchronization + local map cache
The third 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.

The ArcGIS Mobile standard workflow synchronization service was used to support the design analysis. This workflow was generated by the CPT Calculator using a REST Light service with a feature output (display features synchronized with the mobile client application). A 95 percent data cache setting was used to represent traffic for point feature exchanges (only point changes would be exchanged between the client and server displays). Cached reference layers would be distributed to each regional site in advance, and access would be provided by a file share to the ArcGIS Mobile clients running on the local workstations. The ArcGIS Mobile client would synchronize point changes to the dynamic citizen declaration layer over the government WAN. The peak concurrent REST service load would be reduced to 600 concurrent users, representing 25 percent of the total client displays (point changes are made only during edit transactions – 75 percent of the time displays would be supported from local cached features and basemap tiles).

Figure A-4.14 shows the CPT Calculator analysis for the Mobile application with a cached basemap. Standard Xeon E5-2637v4 4 core (1 chip) 3500 MHz servers were used for this assessment.

CPT Workflow: AGS REST 2D V Lite 5%Dyn 13x7 Feature

Peak system requirements:
 * Local copy of cache data used for finding locations (75 percent of workflow)
 * Estimated peak load of 600 concurrent users (edits synchronized with the central data center)
 * Simple mobile application with minimum layers supported by a light workflow
 * Synchronized point feature exchange with central data center, assume less than 95 percent of total display

Hardware solution:
 * 1 Xeon E5-2637v4 4 core (1 chip) 3500 MHz servers
 * ArcGIS Enterprise licensing for up to 4 cores

Peak network traffic estimates: 
 * 1.65 Mbps for large sites, recommend 3 Mbps bandwidth
 * 0.33 Mbps for small sites, recommend 1.5 Mbps bandwidth

Caching advantage summary
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. Greek Citizen Declaration Business Case provides a summary of the CPT Calculator sizing analysis highlighting the advantage of selecting the right technical solution.

CPT Capacity Planning videos
Chapter 4 Capacity Planning Video will discuss best practices for configuring ArcGIS Server for optimum performance and throughput.

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