Implementing ArcGIS Blog

Curious about the performance profile of the ArcGIS Server machine in your ArcGIS Enterprise?
This Article discusses an easy approach for using the Geometry Service to benchmark the underlying processing hardware.

Table of Contents

• Benchmark ArcGIS Enterprise...The Original Approach
• Benchmark ArcGIS Enterprise...An Alternative Approach
• Benefits of Using the Geometry service
• The Geometry_Functions_Benchmark Test Plan
• What Types of Functions Should be Tested?
• Expected Test and Operation Performance
• Deployment Architecture Example
• Benchmark Test Execution
  • Results
  • Calculate Percentage Change
  • Percentage Change Estimate Based on SPEC
• Future Hardware
• Final Thoughts 
  • A Fast Response Time Is All About CPU Speed, Right?
  • What About Other CPU Comparison Tools?
    
    

When people talk about load testing an ArcGIS Enterprise Site, such conversations typically involve the consumption of dedicated or hosted feature services.
For many years, dedicated and hosted services have provided a fast, dependable mechanism for consuming high-traffic map resources online. This has not changed.

However, there is another type of resource to provide maps to users: the Shared Service Instance Pool.
Introduced in 10.7, the shared instances pool make it easier to view and query services that are still important but where memory usage is favored over performance.
This allows for high service density publishing (e.g., being able to publish and have running many services) at the expense of some speed and throughput. It can be a good trade-off considering that for many organizations, there are generally more shared service candidates than dedicated or hosted.

From this advantageous characteristic, shared services have been a true game changer. But, from a load test perspective there are some considerations.

For evaluating Site performance and quantifying service popularity, System Log Parser (SLP) has several report offerings to conduct ArcGIS Enterprise log analysis. When selecting Analysis Types such as Simple, WithOverviewCharts or Complete, there is an
option called "Add Statistics By User to Report" which will include an additional worksheet called Statistics By User into the generated report. The information on this worksheet includes a statistical summary
of successful Portal member requests (as reported by ArcGIS Enterprise). This can be quite helpful for GIS administrators to understanding who is asking for what.
Sometimes however, the listed User on this worksheet may show the value of "anonymous". For a Site with secured services, this might be a puzzling username to observe. This Community Articles helps explains why this can occur.

The purpose of this article is to discuss strategies and concepts for using a JMeter Test Plan to exercise branch versioning editing. The test takes a programmatic approach for creating and capturing the data of important key/value pairs for several of the critical requests.
While a GIS editing test can be complicated since there are many moving parts to keep track of, this Article attempts to simplify the process as much as possible.
The tested workflow utilizes the Natural Earth dataset that is published as a web feature layer with branch versioning enabled.

Table Of Contents

• Branch Versioning
• Why Test Branch Versioning?
• Branch Versioning Editing Testing Challenges
• How to Test Branch Versioning Editing?
  • The Natural Earth Dataset
  • The ArcGIS Pro Feature Cache
• The Editing Workflow via ArcGIS Pro 
• The Branch Versioning Editing JMeter Test Plan
  • Components of the Test Plan
    • CSV Data Set Config
  • (User Test Thread) Initialization Transaction
  • Open ArcGIS Pro Project Transaction
  • Create Version and Switch Version Transaction
  • Add Point Spatially Transaction
  • Update Point Attributes Transaction
  • Polygon Transactions
  • Save Edits (to the Named Version) Transaction
  • Reconcile With Default Transaction
  • Post To Default Transaction
    • Managing the Named Versions
  • Zoom Out (to Scale 1 Million) Transaction
• Final Thoughts
  • Running the Load Test
  • Historic Moment Testing Details
  • Operation Concurrency

Performance with your services and map are extremely important. Better performance means higher scalability which translate to your Site supporting more users. However, there are challenges GIS Administrators face when dealing with performance. This Article discusses some common performance challenges and strategies used to overcome them.

Table of Contents

• Performance: Challenges and Strategies
• What is Performance?
• Why is Performance Important?
• What is Acceptable Performance?
• How is Performance Measured?
  • Capturing Response Times -- Web Browser
  • Capturing Response Times -- ArcGIS Pro
• Are Goals Required for Improving Performance?
• Common Performance Challenges and Potential Strategies
  • Service Pool Types and Instances
    • Selecting the Appropriate Type
  • Focus the Map
    • Map Strategies
  • Software Releases
  • Resource Contention and Expansion
    • Scalability
    • Performance
    • A General Approach to Scaling
  • Observability
    • A Challenge with Common Observability Tools
• Conclusion
  
  

Optimizing the ArcSOC instance availability and utilization for your service is a good strategy for helping users obtain fast response times and lower wait times from their dynamic requests to your Site. It can also benefit server resource utilization like memory as the service is not running a lot of instances that it will never use.

But optimizing the minimum and maximum number of instances for your dedicated services is not a one-time job. Usage patterns of your services can change over time so the task of collecting this information is something that you will want and to revisit periodically as a GIS administrator.

Before diving into how to observe ArcSOC instance activity statistics, let’s review some of the key details of the two ArcSOC-based service types in ArcGIS Server and how they play into this discussion:

• Dedicated
• Shared

Table Of Contents

• ArcSOC Availability and Utilization
• Dedicated Instance Pool Services
• Limitations of Shared Instance Pool Services
• Configured ArcSOC Instance Availability vs Instance Demand
• ArcGIS Server Service Report
• Automating the Service Report Collection with Soccer
• Analyzing the CSV File
• Final Thoughts

Measured transaction throughput and response times are critical data of any ArcGIS Enterprise load test, but captured hardware utilization of the deployment machines provide vital information as well. Together, these test artifacts allow for the proper analysis of the capabilities and efficiencies of the Site.

Determining that an application or feature service has achieved a particular level of throughput is good, but confirming the scalability characteristics while also examining the captured processor utilization of the tested workload is even better.

This Article will discuss several ways to capture the machine hardware utilization. This resource usage is a great compliment to the results of an Apache JMeter load test of ArcGIS Enterprise and can help further the analysis. The Article will focus on the most common scenarios using free tools and utilities for Windows and Linux.

Table Of Contents

• Capturing Hardware Utilization During an Apache JMeter Load Test
• Capturing Strategies
  • What Information Should the Load Test Capture?
  • Sample Interval
  • The Difference Between Capturing and Monitoring
  • Test Clients (Load Generator Machines)
  • Understand Your Server Baselines
  • Common Utilization Capturing Examples
    • Using Perfmon (To Capture Utilization Outside of Load Test)
    • Using dstat (To Capture Utilization Outside of Load Test)
    • Using Apache JMeter (To Capture Utilization Directly From Load Test)
• The SampleWorldCities Test Plan With Metric Collection Support 
  • Components of the Test Plan
    • jp@gc - PerfMon Metrics Collector Extension
  • Validate the JMeter-to-ServerAgent Connectivity
• Test Execution
• General Methodology Guide
• Common Utilization Collection Challenges
• Final Thoughts

Looking for a quick way to summarize the details of all your ArcGIS Enterprise services? If so, then System Log Parser's ServiceDetails Analysis Type is highly recommended. This feature performs a scan of your Site through the REST Admin API and presents the gathered information into a spreadsheet report for easy digestion.

The report is a great resource to find details on your service provider statistics, service configuration info, or data source analysis.

The System Log Parser (SLP) utility is great for being able to analyze many different "ArcGIS Enterprise" log sources to help quantify the usage of your Site. It is free and includes an easy-to-use graphical user interface (GUI) called SystemLogsGUI.exe. But, did you know it can also be run from the command line via the slp.exe that is included with the download?
Command line capable execution makes a good fit for automation through PowerShell or good old fashioned bat scripts.

The slp.exe executable includes all of the same capabilities. However, you can override many of the limits imposed by the GUI such as: the end time and start time. You can even access features that are not available from the GUI like: searching with specific UTC dates, customizing the name of the report, and enabling the application debug log (for troubleshooting).

Although you are probably familiar with using System Log Parser (SLP) to read logs and help you quantify your ArcGIS Enterprise usage, there is a relatively new feature in this popular, free utility that can make the effort easier and the analysis more powerful. 

The new feature, commonly referred to as the Optimized report in System Log Parser, allows you perform log queries of much larger time spans. In addition, it can perform the parsing faster and with tremendous memory savings over the classic analysis types (e.g. Simple, WithOverviewCharts and Complete).

The Optimized option still generates a spreadsheet-based report statistically summarizing the collected log information into key time focused categories.