Back to Top

Introduction

ArcGIS services expose capabilities and make maps and their associated data accessible over the web. A key factor in optimal map service configuration is choosing the appropriate number of service instances, each of which operates as a separate ArcSOC process dedicated to running a map service. An ArcSOC (ArcGIS Server Object Container) is an ArcGIS Server process that runs a GIS service, where each ArcSOC handles one request at a time.

While hosted and shared service types are automatically managed by ArcGIS, map service instance configuration of dedicated services is an often neglected aspect of system optimization. Services and system configuration need to be tested and revisited regularly as services are added or usage patterns change. Otherwise, you might find unacceptable system performance and poor end user experience and efficiency over time.

This test study explores two concepts using dedicated instances with equal minimum/maximum values:

  1. How an under-resourced database impacts broader system usability
  2. How the ratio of ArcSOCs to vCPUs (the number of ArcSOCs configured per vCPU on the ArcGIS Server instance) impacts the system and end user experience

Keep in mind that a dedicated instance that is not running requires some time to start when it receives a request. Our system tests are focused on user experience, so we don’t want to incur the delay of waiting for an ArcSOC to startup. Therefore, for our purposes, all service instances are configured by setting maximum equal to minimum.

Note:

This test study is not intended to recommend a specific ratio of CPU to service instances for every system. Rather, it shows that organizations must perform testing to determine the optimal configuration for their system in a way that balances performance with infrastructure costs. Learn more about how to Monitor system performance.

This study tested real-world workflows against a Network Information Management System hosted in Amazon Web Services (AWS) cloud infrastructure using AWS EC2 instances.

Tested workflows

To ensure the test study provides meaningful results, the workflows need to represent real user experiences, and the actual steps that users will take in interacting with the system. The workflows used in this test study represent some of the foundational activities required to maintain and access an as-built electric network.

The contents of the workflows were defined by experienced staff, along with Esri customer feedback to identify the specific steps, sequencing and type of activities involved in each workflow. The following key workflows were run manually against the system under load to capture user experience and overall performance:

  1. Create a new service with existing feature– provide service from existing transformer
  2. Create new service from new feature – provide service with new pole and transformer
  3. Update asset – move an asset or update attributes
  4. Load management – redirect load from one circuit to another
  5. Phase management – move a service to a different phase
  6. Electric tracing – upstream protective trace and downstream customer trace
  7. View assets – search and view assets and attributes
  8. Summarize assets – identify dirty feeders, counts of new features

You can read more about these workflows in the related system test studies.

Software

The system capabilities are delivered through the following software, deployed, and tested as part of this test study, at the listed versions with all available patches applied:

Top