Building high performance Web applications

There are variables within the Web services architecture that can be measured and modified to improve site performance. Figure 8-15 identifies the associated performance measurements and configuration variables available in tuning an ArcIMS configuration.

Figure 8-15 Web Services Performance

System Design Strategies 8 Software Performance C11144-12

Figure 8-16 identifies performance variables you can measure and how you can modify the map services or component variables to optimize site performance.

Figure 8-16

Web Mapping Services Performance Tuning Guidelines Performance Measure Tuning Options

Transaction Rate Transaction rate identifies the number of requests supported by the site configuration. Peak transaction rate is the maximum capacity of the site to support incoming requests. Peak capacity can be increased by reducing the time required to generate each map service (simpler information products) or by increasing the number of CPUs (more processing power). Sufficient service agent threads should be included to take full advantage of the available CPUs (usually 2–3 threads per CPU is sufficient). Once CPUs are fully utilized, additional threads will not improve site capacity.

No. of Requests in Queue The server object manage acts as a processing queue for inbound requests. Requests are held in the queue until there is a service thread available to process the request. If a request arrives and the service queue is full, the browser will receive a server busy error. Queue depth can be increased to avoid rejecting browser requests.

Transaction Service Time This is the CPU time required to process the published service once it has been assigned to a service instance for processing. Long service times can significantly reduce site capacity and should be avoided if possible. Simple map services (minimum number of layers and simple display functions) can significantly improve site capacity.

CPU Utilization Sufficient service instances should be configured to support maximum CPU utilization.

Maximum site capacity is reached when CPU utilization reaches a peak level (close to 100%

utilization). Increasing service instances beyond this point without increasing the number of processor core will increase the average client reponse time during peak system loads.

Network Traffic Sufficient network bandwidth must be available to support display transport to the client browser. Network bottlenecks can introduce serious client response delays. Bandwidth utilization can be improved by publishing simple map services, keeping image size from 100 KB to 200 KB, and ensuring sufficient bandwidth to support peak transaction loads.

Data Server Memory Sufficient physical memory must be available to support all processing and adequate caching for optimum performance. Memory utilization should be checked once the system is configured to ensure more physical memory exists than what is being used to support the maximum production configuration.

Data Retrieval Time This is the CPU processing time on the ArcSDE server. Query time can be optimized by proper indexing and tuning of the ArcSDE geodatabase.

System Design Strategies 8 Software Performance C11144-12

8.4.1 Configuring the service instances

Web services must be configured with the appropriate number of service instances to take full advantage of the licensed hardware. Each map service is identified by a service configuration, which is represented by a map document (MXD). The Server Object Manager (SOM) deploys the service instances for each service configuration. Figure 8-17 shows the relationship between service instances, threads and ArcSOC processes.

Figure 8-17

Service Instances, Processes, and Threads

From a user perspective, service instances and threads mean the same thing. The service instances managed by the SOM are hosted by the ArcSOC processes (SOC) on the container machine tier.

8.4.2 Selecting high isolation or low isolation

Figure 8-18 shows two different service configurations for an ArcSOC process (high isolation or low isolation).

A high isolation SOC supports only one service thread (instance). A low isolation SOC supports more than one thread (ArcGIS Server 9.2 supports up to 4 threads, and ArcGIS Server 9.3 supports up to 8 threads).

Figure 8-18

Server Object Container (SOC) Isolation

The low isolations SOC are supported by a multi-threaded ArcSOC process. A multi-threaded process is one set of executables shared by more than one service instance, each service instance supported by separate pointers within the ArcSOC process. The ArcSOC process is designed to support execution of the available service instances in parallel (no processing conflicts). Available SOC Threads can support execution of assigned service requests in parallel on separate processor core located on the same platform. The primary

System Design Strategies 8 Software Performance C11144-12

advantage of using a low isolation SOC is to reduce the server platform memory footprint (one set of ArcSOC executables supporting multiple service instances). Single SOC thread failure will kill the complete SOC process, so the high isolation SOC configuration is preferred when sufficient physical memory is available to support the isolation configuration. Standard memory recommendations (2 GB per platform core) should be adequate to support high isolation SOC instances for most ArcGIS Server customer configurations.

8.4.3 Selecting a pooled or non-pooled service model

ArcGIS Server provides options for two different service models (Pooled and Non-pooled). The pooled service model published service instances that can be shared to provide optimum service for large populations of users.

The non-pooled service model assigns each concurrent user session to separate dedicated ArcSOC processes.

Figure 8-19 provides an example of the pooled service model. Many Web application users are accessing the deployed pool of shared service instances. This is the most efficient way to support a large population of users accessing standard Web mapping services.

Figure 8-19 Pooled Service Model

Figure 8-20 provides an example of the non-pooled service model. Each Web application user is assigned a dedicated ArcSOC process to support their workflow. A non-pooled service model would normally be used only when the workflow application requires state changes be maintained at the ArcSOC process level.

Figure 8-20 Non-pooled Service Model

System Design Strategies 8 Software Performance C11144-12

The pooled service model should be used for all service configurations except those that require a non-pooled session. Non-pooled sessions are map editor workflows where MXD context changes are maintained within the ArcSOC process.

8.4.4 Configuring SOM service instances

The SOM service configuration instance settings are very important system capacity parameters.

Understanding how the SOM uses these parameters to manage Web site service capacity will help optimize utilization of the deployed hardware platform configuration. Figure 8-21 provides a view of the ArcGIS Server Map Service Properties template Pooling tab where the service instance configuration is defined.

Figure 8-21

Configuring a Pooled Service

Map Service Properties must be defined for each published service configuration (map service). The minimum number of instances property identifies the number of service instances deployed by the SOM during startup and maintained on the host platforms during light operations. The maximum number of instances property identifies the maximum instances the SOM will deploy during peak load conditions. The SOM will distribute the assigned instances across the available SOC platforms, and will increase and decrease the number of deployed instances within the identified minimum and maximum instance properties based on demand for this service.

System Design Strategies 8 Software Performance C11144-12

8.4.5 Configuring host instance capacity

Each host container machine will have a limited number of processor core (4 core, 8 core, etc) that can be used for processing service requests. Each processor core can handle one service request at a time. Sufficient number of service instances must be deployed to take full advantage of the available processor core. A configuration that allows too many concurrent instances on a limited number of processor core can experience performance degradation during heavy processing loads. Having the right number of service instances to support peak service loads can optimize peak site capacity and user display performance.

Figure 8-22 shows results from a series of tests that demonstrate the optimum map service configuration to optimize system capacity and user display performance.

Figure 8-22 Performance Test Results (Number of Threads makes a difference)

The results show a tradeoff between optimum capacity and user display performance. As the number of available service instances (threads) increased the peak system throughput and utilization would also increase.

As utilization increased above 50 percent of available platform capacity, user display response time would increase; slowing more and more as additional service instances were included in the configuration. The optimum configuration was achieved with 4 service instances (threads) per server core (CPU).

System Design Strategies 8 Software Performance C11144-12

Figure 8-23 shows a view of the Map Services Properties Hosts tab and how the host capacity properties are defined. The default host capacity value is unlimited, which would allow the SOM to deploy the maximum number of instanced defined in all the service configurations at the same time. The host capacity value should be set to optimize system performance during peak system loads. Our recommended setting would be four (4) instances per host platform core (16 instances for 4 core server, 32 instances for 8 core server, etc).

Figure 8-23 Configuring Host Capacity

When configuring high available Web configurations with multiple SOM, separate host capacity configurations must be defined for each SOM environment (each SOM will deploy separate service instances on the assigned host machines - the SOM are not aware of each other and will function as separate environments). System load balancing is managed by each SOM to optimize system performance and scalability - system should be

configured as discussed earlier in Section 4 (Product Architecture).