Performance Management (CPT Demos) 40th Edition

From wiki.gis.com
Jump to: navigation, search
Capacity Planning Tool TABLE OF CONTENTS 40th Edition
1. System Design Process (CPT Demos) 40th Edition 2. GIS Software Technology (CPT Demos) 40th Edition 3. Software Performance (CPT Demos) 40th Edition
4. Server Software Performance (CPT Demos) 40th Edition 5. GIS Data Administration (CPT Demos) 40th Edition 6. Network Communications (CPT Demos) 40th Edition
7. Platform Performance (CPT Demos) 40th Edition 9a. GIS Product Architecture (CPT Calculator Demos) 40th Edition 9b. GIS Product Architecture (CPT Design Demos) 40th Edition
10. Performance Management (CPT Demos) 40th Edition 11a. City of Rome Year 1 (CPT Demos) 40th Edition 11b. City of Rome Year 2 (CPT Demos 40th Edition)


Arc17CapacityPlanning0701 release

Figure A1-10.1 Performance management involves building a design solution based on appropriate workflow performance targets and managing compliance throughout design and implementation to deliver within those targets.
Esri started developing simple system performance models in the early 1990s to document our understanding about distributed processing systems. These system performance models have been used by Esri system design consultants to support distributed computing hardware solutions since 1992. These same performance models have also been used to identify potential performance problems with existing computing environments.

The Capacity Planning Tool was introduced in 2008 incorporating the best of the traditional client/server and web services capacity planning models providing an adaptive sizing methodology to support future enterprise GIS operations. The capacity planning tool methodology is easy to use and provides metrics to manage performance compliance during development, initial implementation, and system delivery.

Figure A1-10.1 shows how system architecture design models can be used for performance management.

  • System architecture design provides a framework for identifying a balanced system design and establishing reasonable software processing performance budgets.
  • Performance expectations are established based on selected software processing complexity and vendor published hardware processing capacity.
  • System design performance expectations can be represented by established software processing performance targets.
  • These performance targets can be translated into specific software performance milestones which can be validated during system deployment.
  • Software processing complexity and/or hardware processing capacity can be reviewed and adjusted as necessary at each deployment milestone to ensure system is delivered within the established performance budget.

Contents

Workflow productivity

Workflow productivity is defined for each project workflow, identifying optimum business requirements for workflow display performance. If the system design does not satisfy identified workflow productivity requirements, the optimum user productivity is not met (work productivity slows down).

CPT Calculator workflow productivity adjustment

Figure A1-10.2 CPT Calculator shows business requirements for ArcGIS Desktop workflows deployed on a single Windows Terminal Server platform that does not satisfy user productivity needs.
The CPT Calculator identifies and optimum user productivity of 10 displays per minute (DPM) for ArcGIS Desktop workflows and 6 displays per minute (DPM) for ArcGIS Server workflows. Workflow productivity is shown in cell B6.

Figure A1-10.2 shows an ArcGIS Desktop Citrix 4x Medium complexity workflow that does not support the optimum 10 DPM productivity (cell B6 is shown in yellow). The Calculator design configuration supports an average of 9.6 DPM for local network clients. The display response times are shown in cells K12:K14.

  • Cell K12 shows average display response time for clients on the local network.
  • Cell K13 shows average display response time for clients at Remote site 1.
  • Cell K14 shows average display response time for clients at Remote site 2.

Average user productivity for remote clients is provided in cells T13:T14.

  • Cell T13 shows average productivity for clients at Remote site 1.
  • Cell T14 shows average productivity for clients at Remote site 2.
Best practice: User productivity constraints can be resolved by updating the hardware or network configuration, or by reducing the workflow display complexity to satisfy business productivity requirements.


CPT Design workflow productivity adjustment

CPT Design productivity adjustment (RESET ADJUST) is an important function used to model system performance on the Design tab. The CPT RESET ADJUST function can be used to identify valid performance values when user productivity is constrained by system performance bottlenecks. The RESET ADJUST function is also used to reserve system resources for batch processing workflows where productivity is constrained by the system configuration.

CPT Design user workflow productivity adjustment
Figure A1-10.3 CPT Design shows business requirements for ArcGIS Desktop workflows deployed on a single Windows Terminal Server platform that fail to satisfy user productivity needs.

Figure A1-10.3 shows the CPT Design tab identifying an invalid design solution.

Peak concurrent user loads are not supported by the selected hardware solution

User workflow requirements include Citrix terminal clients hosted by a centralized WTS platform tier communicating through the data center WAN and Internet gateway connections.

  • Local Area Network includes 88 Citrix users over a 1 Gbps network connection.
  • Remote site 1 includes 10 Citrix users over a 45 Mbps network connection.
  • Remote site 2 includes 2 Citrix users over a 6 Mbps network connection.

The Design shows that clients workflows are not able to maintain their optimum productivity.

  • LAN Workflow (cell E6) due to display response time (Calculated think time less than minimum think time).
  • Remote site 1 workflow (cell E13) due to display response time (Calculated think time less than minimum think time).
  • Remote site 2 workflow (cell E16) due to network contention (workflow traffic more than available bandwidth).

User productivity (column E) must be reduced (slow down) to identify valid system loads.

User productivity is reduced to identify maximum valid solution
Figure A1-10.4 CPT Design shows user productivity reduced identifying maximum workflow performance within restricted server capacity.

Figure A1-10.4 shows the CPT Design tab solution following the workflow productivity adjustment.

CPT Design RESET ADJUST function (cell T2) is used to identify maximum valid solution.

  • Iterative function that adjusts workflow productivity (column E) until calculated think time = minimum think time (columns T and U).
  • Activating function with Blink setting of 10 (cell U:2) will ADJUST productivity to equalize think times.
  • Excel model adjusts user productivity and recalculates values to resolve constraints (iterative calculations).
  • Valid workflow is identified when Calculated think times (Column U) = Minimum think times (Column T) for all workflows.
  • Peak concurrent user cells turn green to show valid workflows.
  • If solution does not resolve with a Blink setting of 10
  • Iterative calculations can diverge if Blink setting (steps) are too large.
  • Reduce Blink setting by factor of 10 to provide more refined step calculations.

Adjusted CPT Design shows the impact of not having adequate system capacity to handle identified workflow loads at the optimum workflow productivity.

  • User productivity less than optimum (column E) for all three workflows.
Best practice: System environment should be upgraded to satisfy user productivity needs.


Batch process loads

GIS analysis often includes batch processing services that consume system resources during peak loads. These batch processing loads must be included in the design analysis to ensure a proper system design solution.

CPT Calculator used to represent a batch process

Figure A1-10.5 CPT Calculator configured with a batch workflow. Batch process has zero (0) think time and client processing load may run on the application server.
Figure A1-10.5 shows the CPT Calculator configured for a batch process.
  • Min think time (cell D6) is set to zero “0”.
  • Client process can be moved to the application tier by selecting “Batch” in cell J15.
  • Calculator will use the selected workflow profile and generate batch loads on the design configuration.
  • Number of batch instances are identified in cell A6 (each batch user instance consumes a processor core).
  • Batch throughput rate (cell C6) is shown in displays per minute (DPM or TPM).
  • Batch transaction response time is identified on Local Client row in cell K12.


CPT Design productivity adjustment used to represent a batch process

System architecture design solutions should include batch processing workflows to reserve resources for geoprocessing services during peak processing loads. Any project workflows with zero minimum think time included in the Design will reserve batch processing resources when using the Design ADJUST function.

CPT Design used to represent a batch process
Figure A1-10.6 CPT Design configured with a batch workflow. Batch process has zero (0) think time and ADJUST function must be used to identify batch loads.

Figure A1-10.6 shows a CPT Design configured with two different batch processes.

  • Batch process is generated from the AGS REST 2D V Med 100%Dyn 13x7 PNG24 workflow. Batch process is initiated by setting the workflow minimum think time = 0 (cell T6) and entering the number of batch instances (Cell C6).
  • Alternative batch process (AGS SOC GeoBatch) is selected from the standard geoprocessing workflows. Minimum think time for the AGS SOC GeoBatch workflow is set at 0 on the Workflow tab (shown in cell T7).
Best practice: Workflow selection should have a similar load profile (client, web, GIS server, SDE, DBMS) as the batch process you wish to model. Display response time (Cell V6) is not important for modeling batch loads.

Platform selection shows a two tier configuration

  • GIS server is Xeon E5-2637v4 4-core (2 chip) 3500 MHz platform.
  • DBMS server is Xeon E5-2637v4 4-core (2 chip) 3500 MHz platform.
Warning: The design loads are not applied until you select the CPT Design RESET ADJUST function to calculate batch productivity.


CPT Design batch workflow software configuration
Figure A1-10.7 Batch process software configuration will identify where processing loads will be applied in the Design analysis.
Figure A1-10.7 shows a batch process two tier software configuration with the client processing load running on the GIS server. The batch process will access data resources from the DBMS platform based on the selected workflow processing profile.


CPT Design batch workflow valid solution
Figure A1-10.8 Batch process productivity calculated using the CPT Design RESET ADJUST function.

Figure A-10.8 shows a CPT Design batch process valid design solution. The batch process productivity must be computed to identify a valid workflow. Productivity will depend on the server loads and available system resources. A single sequential batch process can take advantage of only one processor core.

  • Workflow productivity (cell E6) can be computed using the RESET ADJUST function.

Peak batch instances must be identified in terms of number of Users (column C) or number of Clients (column D).

  • Peak batch throughput (productivity) will depend on available system resources.
  • Column C batch user load works the same as Column D batch client load.
  • A single Batch processes will take advantage of no more than one processor core on each platform.

CPT Design RESET ADJUST function is used to identify maximum valid solution.

  • Blink setting (cell U2) set at 10.
  • Excel computes the batch process productivity (cell E6).
  • Batch client cell turns green with valid solution.

Total batch process instances can be identified in Column D except when TPH is selected in cell D6 (TPH selection interprets selection as transactions per hour).

Examples of workflow loads that can be generated using a batch process:

  • Geoprocessing tasks
  • Spatial analysis tasks
  • Map cache process flow
  • Data processing workflows
  • Replication services
  • GeoEvent Extension streaming services
  • SDE reconcile and post processing
  • Any heavy function sent to a queue for processing
Best practice: Recommended design practice - any heavy function (process that runs more than 30 seconds) that might be requested by multiple users at a time should be configured as a batch process (network services). Processing queue should be established for user work request input. Each batch instance (network service) will process requests sequentially based on available processor resources. User can be notified once their work request processing is complete.

CPT Design batch process performance impacts

System architects and administrators must manage system batch processing loads to avoid user workflow performance impacts. Batch processing services deployed on the same platform as Web mapping services can cause unstable user performance.

Workflow separation best practice: Deploy batch process loads on dedicated platform environments separate from production mapping servers. Batch processing should be deployed on separate ArcGIS Server sites to avoid performance contention.
Web mapping performance baseline
Figure A1-10.9 Web mapping display performance with no concurrent batch processing loads.
Figure A1-10.9 shows user display response time for 100 concurrent users accessing a medium complexity Web mapping service when there are no concurrent batch processes running within the same GIS Server machine cluster.

CPT Design Configuration

  • AGS REST 2D V Med 100%Dyn 13x7 PNG24 Web mapping service (cell B8).
  • 100 concurrent users (cell C8) at 6 DPM productivity (cell E8).
  • Display response time (cell V8) is 0.24 sec.
  • GIS platform E5-2637v4 4 core server (cell B79), single server fixed node (cell H80) can be set to restrict number of servers.
  • GIS platform utilization is 36.2 percent (cell V79).


Batch process performance contention
Figure A1-10.10 Web mapping display performance with concurrent batch processing loads.
Figure A1-10.10 shows user display response time for 100 concurrent users accessing the AGS REST 2D V Med 100%Dyn 13x7 PNG24 Web service when competing for resources along with 3 batch processes running on the same server.

CPT Design Configuration

  • AGS REST 2D V Med 100%Dyn 13x7 PNG24 Web mapping service (cell B8).
  • 100 concurrent users (cell C8) at 6 DPM productivity (cell E8).
  • 3 instances of an AGS REST 2D V Med 100%Dyn 13x7 PNG24 batch service (cell B6).
  • Web service display response time (cell V8) is 5.65 sec.
  • GIS platform E5-2637v4 4 core server (cell B79), single server platform node (cell H80).
  • GIS platform utilization is 99.3 percent (cell V78).


Batch process performance impact summary
Figure A1-10.11 shows a summary of Web mapping display response times impacted by concurrent batch processing loads.
Figure A1-10.11 shows the impact of batch process instances running concurrent with a Web mapping service. Impact is minimum if sufficient resources (CPU utilization) are available to support the required mapping services.

In this example, 100 users accessing the Web mapping services consumed 36 percent of the server resources. Each batch instance will consume one processor core, which is 25 percent utilization on a 4-core server. Web mapping performance was normal when batch processing was limited to 2 concurrent instances. When 3 or 4 batch instances were active, Web mapping service processing had to share available CPU resources with the batch processing loads. As a result, the Web mapping display response times were very slow (over 40 seconds with 4 active batch instances).

Best practice: Keep batch process instances less than available server core when combining with map services.
Warning: Maximum batch process instances equal or greater than available server processor core will consume all available processing resources.


Multi-core platform performance

Figure A1-10.12 Web mapping performance impacted by multi-core queue times
.

Figure A1-10.12 shows the impact of multi-core server configurations on display performance.

CPT Design tab is configured with five separate hardware tier configurations. The virtual server machine configurations for each tier are configured with different number of core.

  • Platform Tier 01: Total of twelve 1-core VMs.
  • Platform Tier 02: Total of six 2-core VMs.
  • Platform Tier 03: Total of four 3-core VM.
  • Platform Tier 04: Total of three 4-core VM.
  • Platform Tier 05: Total of one 12-core VM.

All virtual machines are supported by a common host server platform tier and support a common published service workflow.

  • AGS REST 2D Hvy 100%Dyn 13x7 PNG24 workflow.
  • Xeon E5-2643v4 12 core host platforms.
  • Total host server core is 60 percent more than total virtual core.
  • Hypervisor processing load is supported by host platform, with dedicated core supporting each of the virtual server machines.

CPT is configured to generate peak throughput transaction rates for each tier configuration.

Workflow performance summary

  • Notice service time (column D) for each tier is the same.
  • Notice the same peak throughput is supported by each configuration.
  • Compare display performance for each configuration (1x 12-core configuration is 5 times faster than 12x 1-core configuration).
Best practice: Higher capacity multi-core server machines provided better performance at high utilization loads than single-core platforms.
Note: The difference in peak load display response time can be explained by queueing theory.


ArcGIS Server Site scalability

Figure A1-10.13 ArcGIS Server site medium complexity service scalability CPT Design analysis
Figure A1-10.13 shows a custom CPT Design tab configured to demonstrate ArcGIS Server scalability analysis.

CPT Design tab is configured with fifteen (15) separate hardware tier configurations. Each hardware tier is supported by a different number of server machines.

  • Platform Tier 01: 1 server machine.
  • Platform tier 02: 2 server machines.
  • Platform tier 03: 3 server machines.
  • Platform tier 04: 4 server machines.
  • Platform tier 05: 5 server machines.
  • Platform tier 06: 6 server machines.
  • Platform tier 07: 7 server machines.
  • Platform tier 08: 8 server machines.
  • Platform tier 09: 9 server machines.
  • Platform tier 10: 10 server machines.
  • Platform tier 11: 11 server machines.
  • Platform tier 12: 12 server machines.
  • Platform tier 13: 13 server machines.
  • Platform tier 14: 14 server machines.
  • Platform tier 15: 15 server machines.

Each platform tier is supported by Intel 4-core platforms and share a common published service workflow.

The CPT Design supports two different ArcGIS Server site instance assignment configurations.

  • Multi-cluster site (AGS Site) configuration. Service instance machine assignment is made by each GIS Server based on type of service and service load across machines within each cluster.
  • Single-cluster site (Siloed) configuration. Service instance machine assignment is made by the Web Adaptor or third-party load balancer on arrival at the GIS Server site.

CPT Design configuration mode is selected (AGS Site or Siloed) in column I just above the platform tier.

The custom CPT used in this demonstration is modified to generate peak throughput transaction rates based on each tier configuration.

ArcGIS Server multi-cluster site configuration

The initial ArcGIS 8.1 for Server release supported multiple clusters within a single GIS Server site. The GIS Server multi-cluster site configurations (AGS Site) are cluster-aware, and communicate between machines with each service transaction to provide balanced service assignment within the clusters. As the number of server machines increase, the communication traffic between machines would increase reducing the peak throughput of the deployed GIS Server site configuration.

Medium complexity service scalability
Figure A1-10.14 ArcGIS Server site medium complexity service scalability throughput chart
.

Figure A1-10.14 shows the custom CPT Design tab configured to demonstrate ArcGIS Server site medium complexity service scalability analysis.

Figure A1-10.14 shows the peak throughput loads for this medium Web service workflow. The system scales relatively well for the first 3-4 servers (3-machine site provides 2.7 times the throughput of a single machine site). As the number of machines in the site increase, the internal site communication loads increase. The 15 server machine tier configuration provides less than 6 times the throughput of a single server configuration.

Light 50%Dynamic complexity service scalability
Figure A1-10.15 ArcGIS Server site light 50%Dynamic complexity service scalability CPT Design analysis.
Figure A1-10.15 shows the custom CPT Design tab configured to demonstrate ArcGIS Server site light 50%Dynamic complexity service scalability analysis.

The GIS Server site internal communication loads increases with throughput, and will limit GIS Server site scalability when supporting light service workflows. For this light 50%Dynamic service, the 15 server machine tier configuration provides less than twice the throughput of a single server configuration.

Figure A1-10.16 ArcGIS Server site light 50%Dynamic complexity service scalability throughput chart.
Figure A1-10.16 shows the ArcGIS Server site light 50%Dynamic complexity service scalability throughput chart.

The throughput chart shows how the scalability falls off rapidly as the number of machines in the site increase. The site approaches peak scalability at about 3-5 machines and starts to level off with the higher capacity configurations – additional server machines will not improve system throughput.

Warning: ArcGIS Server light complexity map services do not scale well in a multi-cluster site configuration.


ArcGIS Server single-cluster site configuration (linear scalability)

Figure A1-10.17 ArcGIS Server single-cluster site light 50%Dynamic complexity service scalability analysis
ArcGIS 10.3 for Server introduced a single cluster site configuration option that removes communication between the ArcGIS Server machines to improve scalability. Figure A1-10.17 shows the CPT Design scalability analysis for a single-cluster site (siloed) configuration.

The new single-cluster GIS Server site (Siloed) configurations are not cluster-aware, and service instance machine assignment is determined by the Web Adaptor or third-party load balancer. Machines within the site perform in a Siloed configuration, eliminating the communication overhead that was required for the multi-cluster site configurations.

Figure A1-10.18 ArcGIS Server site light 50%Dynamic complexity service scalability throughput chart
Figure A1-10.18 shows the ArcGIS Server site light 50%Dynamic complexity service scalability throughput chart.

The single-cluster (Siloed) throughput chart shows linear scalability. The 15 server machine tier configuration provides 15 times the throughput of a single server configuration – additional server machines continue to increase system throughput.

Best practice: Deploy light complexity map services in a single-cluster site configuration for optimum scalability.

Single-cluster is the default configuration for the ArcGIS 10.4 server installation. This provides optimum system scalability for the default ArcGIS Server site configurations. With the ArcGIS 10.4 and 10.5 releases, the Administrator can configure the GIS Server site for multi-cluster operations.

ArcGIS Server Virtual Machine (VM) performance

Server virtualization provides many advantages for managing a data center environment. These advantages include server consolidation and system provisioning. Host platform hypervisor manages virtual server core access to available host resources.

The selected host platform supports both GIS Server machine and host hypervisor processing loads.

  • GIS Server processing loads with filtered access through virtual server core.
  • Hypervisor processing loads with direct access to available host platform core.

CPT Design configuration shows an AGS REST 2D V Hvy 100%Dyn 13x7 PNG24 workflow deployed in four separate platform tier configurations.

  • 1x 8-core physical server configuration.
  • 1x 8-core virtual server configuration.
  • 2x 4-core virtual server configuration.
  • 4x 2-core virtual server configuration.
  • 8x 1-core virtual server configuration.


Host machine with 50 percent additional core available for hypervisor loads

Figure A1-10.19 CPT Design analysis: ArcGIS Server deployed in virtual server machines with dedicated access to host platform core
.

Figure A1-10.19 compares ArcGIS Server performance between an 8-core physical server configuration and four separate 8-core Virtual Server configurations. Each virtual server tier is supported by a dedicated 12-core host platform tier.

Workflow performance summary.

  • Measured service time was the same for all four platform tier configurations.
  • Peak throughput (90% rollover) was same for all four platform tier configurations.
  • Host platform tier had extra core to support hypervisor processing loads.
  • 8-core virtual machine had same response time as 8-core physical machine.
  • 1-core, 2-core, and 4-core virtual machine display performance was slower due to queuing delays.


Figure A1-10.20 Peak throughput chart: ArcGIS Server deployed in virtual server machines with dedicated access to host platform core
.

Figure A1-10.20 shows virtual server throughput was the same as the physical server throughput.

Best practice: Provide host platform with 50 percent more processing capacity that required by the virtual servers.


Host machine with Virtual Servers and Hypervisor sharing same physical core

Figure A1-10.21 CPT Design analysis: ArcGIS Server deployed in virtual server machines competing with hypervisor for access to host platform core
.

Figure A1-10.21 compares ArcGIS Server performance between an 8-core physical server configuration and three separate 8-core Virtual Server configurations. Each virtual server tier is supported by a dedicated 8-core host platform tier.

Workflow performance summary.

  • Measured service time was the same for all four platform tier configurations.
  • Peak throughput (90% rollover) was same for all four platform tier configurations.
  • Host platform tier had same number of core as the virtual server tier.
  • 8-core, 4-core, and 2-core VM had same response time as 8-core physical machine (queue time dominated by host platform contention). Host core shared by virtual machines and hypervisor processing loads.
  • 1-core display performance was slower due to slightly higher queuing delays.
  • Virtual Server throughput peaks at 60% utilization.


Figure A1-10.22 Peak throughput chart: ArcGIS Server deployed in virtual server machines competing with hypervisor for access to host platform core
.

Figure A1-10.22 shows virtual server throughput was 66% of the physical server throughput due to host platform hypervisor loads.

Warning: Hypervisor load will restrict virtual server throughput when host platform has limited processing resources.


Performance Validation

Planning provides the first opportunity for building successful GIS operations. Getting started right, understanding your business needs, understanding how to translate business needs to network and platform loads, and establishing a system design that will satisfy peak user workflow requirements is the first step on your road to success.

Planning is an important first step – but it is not enough to ensure success. If you want to deliver a project within the initial planning budget, you need to identify opportunities along the way to measure progress toward your implementation goal. Compliance with performance goals should be tracked throughout initial development, integration, and deployment - integrate performance validation measurements along the way. Project success is achieved by tracking step by step progress toward your implementation goal, making appropriate adjustments along the way to deliver the final system within the planned project budget. The goal is to identify problems and provide solutions along the way - the earlier you identify a problem the easier it will be to fix. System performance can be managed like any other project task. We showed how to address software performance in Chapter 3, network performance in Chapter 5, and platform performance in Chapter 7. If you don’t measure your progress as these pieces come together, you will miss the opportunity to identify and make the appropriate adjustments needed to ensure success.

There are several opportunities throughout system development and deployment where you can measure progress toward meeting your performance goals. The CPT Test tab includes four tools you can use to translate live performance measurements to workflow service times – the workflow performance targets used to define your initial system design.

Map display render times

In Chapter 3 we shared the important factors that impact software performance. For Web mapping workflows, map complexity is the primary performance driver. Heavy map displays (lots of dynamic map layers and features included in each map extent) contribute to heavy server processing loads and network traffic. Simple maps generate lighter server loads and provided users with much quicker display performance. The first opportunity for building high performance map services is when you are authoring the map display.

There are two map rendering tools available on the CPT Test tab that use measured map rendering time to estimate equivalent workflow service times. One tool is available for translating ArcGIS Desktop map rendering times (MXD) and the other tool is for translating ArcGIS Server map service rendering times (Preview). With both tools, measured map rendering time is translated to workflow services times that can be used by the CPT Calculator and Design tabs for generating your platform solution. The idea is to validate that your map service will perform within your planned system budget by comparing the workflow service times generated from your measured rendering times with your initial workflow performance targets. If the service times exceed your planned budget, you should either adjust the map display complexity to perform within the initial planning budget or increase your system performance budget. The best time to make the map display complexity adjustment is during the map authoring process. Impacts on the project budget can be evaluated and proper adjustments made to ensure delivery success.

Measured MSD render time

Figure A-10.23 The CPT Test validation tool used for translated measured map service Preview render times to workflow service times.

Figure A1-10.23 shows a tool you can use to translate measured map publishing Preview render time to workflow service times. Preview render time can be measured when publishing your map service using the service editor preview tool.

Warning: Make sure to measure a map location that represents the average map complexity or higher within your service area extent and adjust preview to average client display resolution. Use a local FGDB data source to collect proper measurement.
Note: Pan or Zoom of the ArcGIS Server service editor preview window will provide render time for fresh dynamic display

The Measured Performance tool can be used to estimate workflow service times from a measured Preview render time.

  • Select Preview in cell B12.
  • Select Test Platform processor configuration in cell A14 (workstation or server platform used to render the map). Selection is from platforms in the CPT Hardware tab.
  • Select Software Technology map service in cell A16.
  • If using a platform with turbo-boost capability, set maximum turbo-boost MHz in cell D13.
  • Enter measured Preview display render time in cell A18.

Baseline workflow service time is provided in range D15:21.

  • Workflow service times are also provided on the CPT Workflow tab under the Test Workflows section.


Measured MXD render time

Figure A1-10.24 The CPT Test validation tool used for translated MXDPerfStat render times to workflow service times.

Figure A1-10.24 shows a tool you can use to translate measured MXDPerStat render time to workflow service times. MXD render time can be measured using the MXDPerfStat ArcScript performance measurement tool.

Warning: Make sure to measure a map location that represents the average map complexity or higher within your service area extent. Adjust map display to average client display resolution. Use a local FGDB data source to collect proper measurement.
Note: MXDPerfStat tool uses the Windows rendering engine to measure display performance at a selected location and map display extent, identifying render time for each scale included in the selected map document

The CPT Measured Performance tool can be used to generate workflow service times from the measured MXD display render time.

  • Select MXDperfstat in cell B12.
  • Select Test Platform processor configuration in cell A14.
  • Select Software Technology map service in cell A16.
  • If using a platform with turbo-boost capability, set maximum turbo-boost MHz in cell D13.
  • Enter measured MXDperfstat display render time in cell A18.

Baseline workflow service time is provided in range D15:21.

  • Workflow service times are also provided on the CPT Workflow tab under the Test Workflows section.

Measured throughput and platform utilization

Figure A1-10.25 The CPT Test validation tool used for translated measured map service throughput and platform utilization to workflow service times.

If you know your platform configuration, your measured peak workflow throughput, and the associated platform utilization the CPT can calculate the workflow service times. The Test tab translation tools can be used to input throughput (transaction per hour), the platform configuration (server platform selection), and the measured platform utilization and excel will translate these inputs to equivalent workflow service times. Figure A1-10.25 shows the inputs required for completing this transaction.

Best practice: Performance metrics can be collected from benchmark test or live operations.
Warning: Make sure all measurements are collected for the same loads at the same time.

The Live Results tool can be used to generate workflow service times from throughput and utilization measurements.

  • Enter throughput in cell A3.
  • Select test platform configuration in range E4:10.
  • Identify number of platform nodes in range D4:10.
  • Enter measured utilization for each platform in range B4:10.

Baseline workflow service time is provided in range G3:10.

  • Workflow service times are also provided on the CPT Workflow tab under the Test Workflows section.

Translate measured traffic to workflow transaction Mbpd.

  • Enter measured traffic in cell C3.
  • Enter test bandwidth in cell E3.
  • Workflow transaction Mbpd is provided in cell F3 and on the Workflow tab.


Measured peak concurrent users and platform utilization translator

Figure A1-20.26 CPT Test validation tool used for translated map service peak concurrent users and platform utilization to workflow service times.

If you don’t have measured throughput, concurrent users working on the system can be used to estimate throughput loads. This is a valuable tool for using real business activity to validate system capacity (business units identify peak user loads and IT staff identify server utilization observed during these loads). The Test tab can be used to input throughput (peak concurrent users), the platform configuration (server platform selection), and the measured platform utilization and excel will translate these inputs to equivalent workflow service times. Figure A1-20.26 shows the inputs required for completing this transaction.

Best practice: Analysis assumes peak users are working at web power user productivity (6 DPM) over a reasonable measurement period (10 minutes).
Warning: Make sure all measurements are collected for the same loads at the same time.

The Live Results tool can be used to generate workflow service times from peak concurrent users and utilization measurements.

  • Enter peak concurrent users in cell A5.
  • Select test platform configuration in range E4:10.
  • Identify number of platform nodes in range D4:10.
  • Enter measured utilization for each platform in range B4:10.

Baseline workflow service time is provided in range G3:10.

  • Workflow service times are also provided on the CPT Workflow tab under the Test Workflows section.

Translate measured traffic to workflow transaction Mbpd.

  • Enter measured traffic in cell C3.
  • Enter test bandwidth in cell E3.
  • Workflow transaction Mbpd is provided in cell F3 and on the Workflow tab.


Move Test tab derived workflow service times to project workflows.

Figure A1-10.27 Workflows generated on the CPT Test tab can be transferred to your project workflows on the CPT Workflow tab.

The CPT Workflow tab is where the results of your performance validation efforts come together. Figure A1-10.27 shows how each of these test results can be brought together, along with the original workflow service times, to validate that you are building a system that will perform and scale within your established project performance budget.

Moving workflows to your Project Workflow list.

  • Test workflow service times show up in the Test Workflows section on the Workflow Tab.
  • Add an extra workflow in your Project Workflows to use as a template.
  • Copy blue portion of Test Workflow.
  • Select first column cell of template workflow.
  • Paste special/values to your new workflow template in the Project workflows.
  • Complete the Description of new workflow in column AB.
  • Insert nickname in workflow cell in Column A.
Best practice: Performance management, including performance validation throughout development and system delivery, is the key to implementation success. It is important that you identify the right technology and establish reasonable performance goals during your initial system design planning. It is even more important that you monitor progress in meeting these goals throughout final system development and delivery.

CPT Capacity Planning videos

Chapter 10 Capacity Planning video shows how to use the CPT Design adjust function to identify performance impact of undersized systems, how to represent a batch process in your design, and how to use the CPT to translated measured system performance to workflow services times to validate deployed services are performing within the performance budget established in your system design.

Capacity Planning Tool TABLE OF CONTENTS 40th Edition
1. System Design Process (CPT Demos) 40th Edition 2. GIS Software Technology (CPT Demos) 40th Edition 3. Software Performance (CPT Demos) 40th Edition
4. Server Software Performance (CPT Demos) 40th Edition 5. GIS Data Administration (CPT Demos) 40th Edition 6. Network Communications (CPT Demos) 40th Edition
7. Platform Performance (CPT Demos) 40th Edition 9a. GIS Product Architecture (CPT Calculator Demos) 40th Edition 9b. GIS Product Architecture (CPT Design Demos) 40th Edition
10. Performance Management (CPT Demos) 40th Edition 11a. City of Rome Year 1 (CPT Demos) 40th Edition 11b. City of Rome Year 2 (CPT Demos 40th Edition)

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