Conclusions and key takeaways

Throughout the five test runs, it was clear that the under-resourced database instance in the first test run noticeably degraded system performance and user experience. Once the database instance was properly sized for our workloads, the ArcSOC : vCPU ratios had a smaller impact on workflow execution times. Looking at the table below, we can see the 1:1 ArcSOC : vCPU ratio imposed some additional wait times (0.246s) on viewing workflows, but didn’t significantly impact editing workflows (see P99 Waits HS). This is likely due to busy ArcSOCs on the hosting server.

The 2:1 ratio produced nearly identical workflow execution times with no significant waits, but did have high memory utilization on the UN GIS Server (82%). The 2:1 ratio is too high for these versioned editing workflows, where max ArcSOCs on the UN GIS Server only reach 7. Therefore, by increasing ArcSOCs on the UN GIS Server, we are only wasting server resources. However, the hosting server, supporting view-only workflows, easily supported the 2:1 ratio. The UN GIS Server needs more memory to support ratios at 2:1 and beyond. At 4:1, the hosting server also needs more memory.

Resource utilization

We concluded that adding more service instances did not result in better user experience for editors, although it may improve responsiveness in our view workflows by reducing wait times. We saw that even ArcSOCs that were not in use were still consuming server resources. The table above shows workflow times slightly increasing as the ArcSOC : vCPU ratio is increased.

This implies that the additional available ArcSOCs were not necessary to support user requests and were unnecessarily consuming system resources (primarily memory). The table above confirms that editing workflows did not take advantage of the additional ArcSOCs, but the view workflows with much higher operations per hour did. Therefore, for our system, a 2:1 ratio of ArcSOCs to vCPU was most optimal for view only services on the hosting server and 1:1 is most optimal on the UN GIS Server.

Key takeaways

• An under-resourced database instance negatively impacted the whole system:

  • For our system, we determined the larger geodatabase instance size (16 vCPU) was critical

  • ArcSOCs, GIS Server CPU, and Web Adaptors were busy, making performance issues appear to be system wide

  • Workflow execution times took roughly twice as long to complete with an undersized database

  • An under-resourced database impacted performance significantly more than poorly configured map instances

  • Simply increasing database resources greatly improved system behavior and performance

• With a properly resourced database, increasing the ratio of ArcSOCs (map service instances) to vCPU did not improve the end user experience or workflow execution times

• Adding unnecessary service instances can negatively impact the system by consuming unnecessary additional resources

• Increasing the number of running map instances will impact GIS Server memory utilization, even when they are not busy

• Workload separation remains important - feature services exposing versioned data will use more GIS Server memory than view-only services

  • The available resources (CPU, RAM, and Disk I/O) on the database instance significantly improved the entire system’s ability to handle load

• At a minimum, monitor database CPU, ArcSOC usage, GIS Server resources, and user experience to identify the optimal configuration for your system, especially after making any changes