Performance Management (CPT Demos) 37th Edition
The Capacity Planning Tool was introduced in 2008 incorporating the best of the traditional client/server and web services sizing 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
CPT Design workflow productivity adjustment
CPT Design productivity adjustment (RESET ADJUST) is an important function used to model system performance. The CPT RESET ADJUST function can be used to identify valid user productivity 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.2 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 editors and viewers hosted by a centralized WTS Platform communicating through the data center WAN and Internet gateway connections.
- Local Area Network clients include 10 Editors and 40 viewers.
- WAN clients include 10 editors and 30 viewers.
The single Citrix WTS server platform is showing an overcapacity load of 102.8 percent.
This is an invalid solution.
- Platform utilization is over 100%.
- User productivity (column E) must be reduced (slow down) to identify a valid system loads.
- User productivity is reduced to identify maximum valid solution
Figure A1-10.3 shows the CPT Design tab solution following the workflow productivity adjustment.
CPT Design RESET ADJUST function 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 to equal think times.
- Function "blinks" between positive and negative calculated think time values.
- Blink setting is reduced to 1 and calculation resolves for all workflows.
- Calculated think times = Minimum think times.
- Peak concurrent user cells turn green to show valid workflows.
CPT Design shows the impact of not having adequate server capacity to handle identified workflow loads.
Best practice: System design should be upgraded to satisfy user productivity needs.
CPT Design productivity adjustment used to represent a batch process
Figure A1-10.4 shows a CPT Design configured with a two different batch processes.
- One batch process (S Batch) is selected from the sample workflows. Minimum think time for the S Batch workflow is set at 0 on the Workflow tab.
- A second batch process is generated from the sample S WebMap workflow. Batch process is initiated by setting the S WebMap workflow minimum think time = 0 (cell T7).
Best practice: Workflow selection should have the same load profile (client, web, GIS server, SDE, DBMS) as the batch process you wish to model. Total processing time is not important for modeling batch loads.
Platform configuration is a two tier configuration
- GIS server is Xeon E5-2637v3 4-core (2 chip) 3500 MHz platform.
- DBMS server is Xeon E5-2637v3 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.
Figure A-10.5 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 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 process load works the same as Column D.
- 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 (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 (runs more than 30 seconds) that might be requested by several users at a time should be configured as a batch process (network services). Processing queue must 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 is services.
CPT Design evaluation of physical and virtual multi-core performance
Figure A1-10.6 shows how platform queue time contributes to server performance.
The CPT Design is configured to represent 4 different test environments. Same workflow and physical server platforms are used for each test case.
- Server platforms: Xeon E5-2637v3 4 core (1 chip) 3500 MHz
- Published service: AGS103 REST MSD R 100%Dyn Med 13x7 JPEG
Each test environment is supported by a single platform tier. Each environment includes the same number of processor core (4 core). The four test configurations include the following:
- Platform tier 07 is configured as 2 physical 2-core machines.
- Platform tier 08 is configured as 1 physical 4-core machine.
- Platform tier 09 is configured as 2 virtual 2-core machines.
- Platform tier 08 is configured as 1 virtual 4-core machine.
Each workflow load was increased until display response time reached two seconds.
Peak system loads with display response time = 2 seconds
- Two physical 2-core servers:
- Peak throughput = 79,950 (97.7 percent of physical 4-core throughput)
- Platform utilization = 95.3 percent
- One physical 4-core server:
- Peak throughput = 81,870 (highest throughput for all configurations)
- Platform utilization = 97.6 percent
- Two virtual 2-core servers (service time increase 10 percent over physical machines):
- Peak throughput = 72,300 (88.3 percent of physical 4-core throughput)
- Platform utilization = 94.8 percent
- One physical 4-core server (service time increase 20 percent over physical machines):
- Peak throughput = 67,860 (93.8 percent of Virtual 2-core throughput)
- Platform utilization = 97.1 percent
Virtual Server performance overhead increases service time for multi-core servers. As a result, peak throughput performance degrades with increasing number of virtual core.
Initial CPT releases applied 10 percent processing overhead per core for virtual server environments. More recent virtual environments do not require as much overhead, and CPT Virtual Server overhead planning factors were reduced with the July 2013 release.
Arc13CapacityPlanning0701 applied virtual server overhead:
- 1-3 core/node, 10 percent overhead
- 4-6 core/node, 20 percent overhead
- 7 or more core/node, 30 percent overhead
Best practice: For physical server platforms with same per core performance, more cores per server provides more throughput. For virtual server platforms with reduce per core performance, fewer cores per server provides more throughput.
Warning: More cores per server improves throughput only when display service times remain constant between configurations.
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 for Desktop map rendering times (MXD) and the other tool is for translating ArcGIS for 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 A1-10.7 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 for Server service editor preview window will provide render time for fresh dynamic display
The Measured Performance tool can be used to generate 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.8 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
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.9 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
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-10.10 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.
The CPT Workflow tab is where the results of your performance validation efforts come together. Figure A1-10.11 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.
Page Footer
Specific license terms for this content
System Design Strategies 26th edition - An Esri ® Technical Reference Document • 2009 (final PDF release)
