Server Software Performance

From Wiki.GIS.com

Jump to:navigation, search
System Design Strategies (select here for table of contents)
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 B1. Windows Memory Management Preface (Executive Summary) SDSwiki What's New



Fall 2014 GIS Server Software Performance 35th 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.

Contents

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 from ArcGIS 10 to ArcGIS 10.1 and beyond. The new ArcGIS for Server architecture changes were made to make Server much easier to deploy and manage in an adaptive virtualized server environment.

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 presented July 25, 2012. 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.2 architecture 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.

ArcGIS for Server Site

An ArcGIS for Server site refers to one or more GIS Servers with a common configstore.

Server process

A server process refers to a software server executable.

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.

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 instance

Service instance is a process thread made available for servicing a map request. The service configuration identifies the minimum and maximum number of service instances that will be deployed by ArcGIS for Server to satisfy inbound web service requests.

Service instance configuration

Each published service has a defined service instance configuration which represents how that service can be serviced through the software stack. Service instance configurations are assigned to service clusters, and multiple service clusters can be assigned within a server site.


Pooled service model (service instance settings)

Figure 4.3 Pooled SOC.exe processes provide optimum execution throughput.

Figure 4.3 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 and later releases.

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

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.

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


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

Figure 4.4 ArcGIS for Server pooling settings are used to select service configuration minimum and maximum service instance configurations.

Figure 4.4 ArcGIS Service Editor pooled service instance settings. The service instance parameters are identified under Service Editor Pooling.

Minimum and maximum service instance setting:

>Minimum service instances are deployed during GIS Server startup and after idle instance timeout.
>Maximum service instances establish limit for GIS Server service instance deployment.

Timeouts (reference Figure 4.3):

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. Reduces number of deployed service instances to minimum setting when request for this service has not been received for this amount of time.


ArcGIS for Server process configuration

Figure 4.5 Server executables can be configured as either high isolation or low isolation processes.

Figure 4.5 shows the available ArcGIS for Server SOC process configurations. There are two types of SOC executable configurations, high isolation and low isolation. Process isolation settings are configured when publishing the service.

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

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

Set maximum instances per ArcSOC process.

Warning: Low isolation GIS Server configurations with several instances per SOC can result in unstable server performance

Recycle time schedules GIS Server service instance recycle operations.

Keep alive connections.


Cached map service

Figure 4.7 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 for Server provides map cache services 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 SDKs. 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. For optimum 3D performance, tiles can be delivered from a 3D Globe cache.

Figure 4.7 provides an overview of the cached map service image structure. ArcGIS for Server includes automated geoprocessing services 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.

Rapid display of static base maps.

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


Map service caching configuration

Figure 4.8 Service editor caching capabilities allow you to specify if the service will be cached during the map service publishing process.

Figure 4.8 shows a view of the ArcGIS Service Editor Caching settings. A Portland 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 publish a dynamic or cached service. You can have the cache creation start automatically once you complete the configuration, or save the configuration and start the caching job manually at a later time.

Draw this map service:

Caching settings

Identify caching method

Warning: Map cache service instances will consume CPU resources. Do not use the ArcGIS for Server production site for manually building your cache
Best Practice: Use preconfigured CachingTool instances when generating map cache. Batch processing loads for maximum CachingTool service instance configuration must be included in your capacity planning analysis to ensure adequate server resources during peak loads.

Advanced settings

Figure 4.9 Service Editor advanced service caching parameters identify when and how the service caching job will be run.

Figure 4.9 shows three options available for map service caching.

Warning: Map cache processing instances will consume CachingTools service instances while generating the cache. If all published CachingTools instances are busy, caching job will wait in queue until service instances are available.
Best Practice: Partial cache can reduce overall caching time. For most implementations, service requests access a relatively small area of the total dataset.
Best Practice: Cache on demand should only be used for generating cache on sparsely populated areas (map request for that area of the map would be a rare event).

Additional Advanced caching settings

Figure 4.10 Service Editor Advanced Cache Settings include important settings impacting display performance.

The Service Editor Caching Advanced Settings tab includes an additional Advanced Cache Settings tab (Figure 4.10) that is important to review. This tab includes three very important performance settings:

Best Practice: Map cache clients should periodically clear their local browser cache to ensure use of the latest tile updates available on the server.

Map Service instance configuration strategies

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 physical core processor configuration.

Batch process service configuration (geoprocessing services)

Figure 4.11 Batch process load profile

The purple line in Figure 4.11 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 (white 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 roughly 25 percent host platform utilization with peak throughput of 190 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 approaches 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 over 99 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 than 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.

Service configuration min/max instance setting impact server performance.

Best Practice: Set map service configuration minimum and maximum instance settings to optimize site performance. If you need to work on the site cluster during batch geoprocessing, you may want to configure less than N+1 instances to allow for an administrative processing reserve.

Optimum service instance configuration:

Many ArcGIS services perform as batch processes.

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 batch service productivity for the maximum server load.

Design batch process instance configuration

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

Web service instance configuration (concurrent users)

Figure 4.12 Web mapping service instance load profile.

The purple line in Figure 4.12 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 (white processing queue times due to 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 less than 38 percent host platform utilization with peak throughput of 287 DPM and display response time just over 0.40 seconds, well below the maximum host platform throughput capacity. The eighth bar represents a service configuration with sixteen (16) service instances. Host platform is over 92 percent utilization with a display response time over 1.35 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 (12 to 20 service instances on a 4-core host platform). Increasing the number of service instances beyond this level will only increase the average display response time with minimal throughput gain.

Random arrival distribution reduces peak throughput per service instance.

Service configuration min/max instance settings impact server performance.

For a popular service, the maximum service instances 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.

CPT Design map service instance configuration

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

Generating the map cache

ArcGIS Server creates cache tiles using a geoprocessing service named CachingTools. This service is configured for you in the System folder when you create the ArcGIS Server site. The number of instances you allow for the CachingTools service determines how much power your machine can dedicate toward caching jobs.

Estimated map cache generation time

Figure 4.13 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.13 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.

Rendering time increases exponentially with each tile layer.

Estimating map cache generation time.

Warning: The caching process can be time consuming.


Cache processing profile

Figure 4.14 Caching timelines are reduced linearly based on the number of available processor core.

Figure 4.14 provides an example of taking advantage of the hardware, as described above. ArcGIS for Server will use the CachingTools 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. Recommended CachingTools service instance configuration is N+1, where N=number of physical server core processors. If you want to view caching status and manage cache jobs while executing the cache, maximum number of instances = physical server process core leaves some processing resources for managing caching services.

Testing was performed on identical 4-core server platforms.

Best Practice: Take advantage of available hardware resources


Figure 4.15 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. CPU usage should peak at 100 percent when running with N+1 service instances with hyperthreading disabled.
Warning: ArcGIS 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 in ArcGIS for Server] provides a demo showing the new workflows and features of map caching in ArcGIS 10.1 for Server.

Manage Services caching tools

Figure 4.16 Managed Services caching tool services are configured by the ArcGIS Server Manager during the initial site install.

Manage services caching instances are configured during site installation to enable background caching services.

Service Editor service configurations apply to every GIS Server machine within the assigned cluster.

Best Practice: Managed Services caching tools should be configured in a separate ArcGIS for Server Site cluster from production Web services.

Production servers within the GIS Server Site can be reassigned to the Map Caching cluster to expand caching capacity during off-peak hours.

System Caching Processes configurations

Figure 4.17 CachingControllers process configuration should be set at high isolation for optimum stability.

Figure 4.17 shows the CachingController processes configuration. An identical tab will be configured for the CachingTools processes configuration.

Map cache generation is an intense batch process which can often run for hours and days at a time often generating hundreds of thousands of cached map tiles. It is important to support this type of service with the most stable process configuration. For this reason, both the CachingController and CachingTools SOC processes should be configured in high isolation mode.

Recycling the processes can ensure stable instances during the map cache build, promoting optimum performance during cache generation. Caching jobs are processed in bundles of 16,384 tiles. CachingTools instances can be recycled between processing bundles once during each recycle process. CachingControllers and CachingTools processes configurations should be scheduled for a recycle every 24 hours to promote optimum site stability and performance. CachingController instances will recycle between caching jobs. CachingTools instances can recycle during job processing between bundle caching assignments.


System Caching Pooling configurations

A dedicated CachingControllers instance is required for each caching job. Pooling and Processes settings must be configured for the CachingControllers service. CachingTools will be configured to optimize utilization of available platform hardware resources during peak cache processing loads.

Figure 4.18 CachingTools service instance configuration should be set based on total GIS server machine cores (N+1) for optimum caching throughput.

Figure 4.18 shows the CachingTools processes configuration. An identical tab will be configured for the CachingControllers processes configuration.

CachingControllers Pooling settings
CachingTools Pooling settings

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

The CachingControllers manage caching jobs to take advantage of all available CachingTool service instances. For a single caching job, the CachingController will assign multiple caching processes to leverage all available CachingTool service instances (up to the total number of bundles in the caching configuration). Multiple concurrent jobs will share available CachingTool service instances. Assignment of multiple concurrent caching jobs (multiple CachingControllers) will optimize utilization of available server processing resources.

Timeout settings should be appropriate to the caching service.

Best Practice: Think carefully what works best for your Site's caching jobs and select appropriate service instance configurations and timeout settings to optimize utilization of your server environment.


GIS Server machine memory configuration

Figure 4.19 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.19 shows memory performance considerations for an ArcGIS Server host machine deployment.

Best Practice: Sufficient platform physical memory is critical to successful stable operations. More memory can improve performance.

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

Too many instances per server can exhaust memory.

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

Too few instances per server:

Best Practice: Provide sufficient memory to support optimum performance.

ArcGIS for Server memory recommendations

ArcGIS platform memory recommendations

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

Managing host platform service instance capacity

There are a handful of GIS Server terms and configuration variables – 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 manages the internal ArcSOC service instance deployment 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 (service instances) 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 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 the total of several active services to be 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.exe 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 (max idle time).

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 the service logs to see if your settings are working. Modifications can be applied to optimize your specific service loads. 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. Sufficient memory must be available to handle the maximum number of active service instances or the system can become unstable. Remember, the goal is to configure the system to minimize processing overhead during peak throughput periods (excessive SOC process start-up loads during peak service periods is overhead you would like to avoid).

Additional ArcGIS platform memory configuration guidelines are provided in the appendix on Windows Memory Management.

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.20 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.20 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.21 This network diagram shows the central National Data Center and sample small and large regional centers used in completing the design.

Figure 4.21 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


Web mapping services architecture patterns.

Figure 4.22 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.22 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.

CPT Workflow: AGS10 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.

CPT workflow: AGS10 ADF MXD R 100%Dyn Lite 10x7 JPEG
CPT workflow: RESTdyn_Composite Workflow from the following composite recipe:
  • Basemap_AGS102 REST MSD R 90%Dyn Lite 10x7 JPEG
  • busLayer_AGS102 REST MSD R 10%Dyn Lite 10x7 Feature
  • 100 percent dynamic
CPT Workflow: AGS102 REST MSD V 10%Dyn Lite 10x7 Feature +$$
CPT Workflow: AGS102 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.


Web 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:

Total estimated technology cost of $625,000

Peak network traffic estimates

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:

Total estimated technology cost of $360,000

Peak network traffic estimates


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:

Total estimated technology cost of $125,000

Peak network traffic estimates

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:

Total estimated technology cost of $70,000

Peak network traffic estimates:


Caching advantage summary

Figure 4.23 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.23 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.

CPT Capacity Planning videos

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

Server Software Performance 34th Edition
Server Software Performance 33rd Edition
Server Software Performance 32nd Edition
Server 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)
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 B1. Windows Memory Management Preface (Executive Summary) SDSwiki What's New

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

Navigation
Need Help
Toolbox
Share This Page