When working with ArcGIS web services, sooner or later the question comes up: “how good will performance be, given expected usage?” Or: “how will publishing and using a certain set of services be affected by the rest of the services running in the same environment?

Performance planning for Esri services can be done in more or less sophisticated ways (e.g using ArcGIS SystemDesigner) but, realistically, the real-life performance is not known until testing the actual behaviour under a given load. Before and after system updates/upgrades, both software and hardware, it would be awesome to know whether performance has improved or suffered.

Alternatively, ArcGIS Administrators may be interested in measuring a baseline performance before publishing new capabilities. In our case I was particularly interested to get a feeling for ‘normal’ performance at different times of the day, considering that public users all over the world may be accessing our services with varying volumes at different times of the day. In other words, I was keen to detect whether behaviour was different during different times of the day, or on different week days. Additionally, it seemed like a great option to compare the actual performance of our Pre-Production and Production environments, respectively. The two environments are (meant to be) identical, but storage mechanisms for the attached network drives differ in practice.

So what we will measure is the actual ‘throughput’ which is influenced by many factors that we can’t directly know without more detailed metrics for various parts like the network, drives etc. Ultimately we will know how much ‘comes through’ at the end where we are testing (the server where our JMeter test run) depending on what load we apply. If that throughput is different at different times of the day, other things will need to be investigated.

The Apache JMeter tool for such testing is available free . The Esri community “Implementing ArcGIS Blog” from members of the Esri Professional Services team and was instrumental in finally trying out the method against our ArcGIS Server services, in an ArcGIS Enterprise environment.

This kind of ‘controlled load’ testing will allow us to gauge the number of possible concurrent users that our system is able to sustain without performance degradation by returning throughput metrics, that can be graphed to give us an idea of the maximum load where performance starts to suffer (JMeter can create report output that show such curves for throughput and performance). In addition, we can visually check server hardware metrics to get a better feeling for the actual load generated by certain types of requests.

This is obviously only a start and I am eagerly waiting to combine this test with more holistic hardware and service monitoring in ArcGIS Monitor.