How to read server statistic correctly

[yockee]

I need a better understanding about reading server stats.

I have like a total of 10-12 map services. All hosted on AWS, single server.

I monitor all of them by reading their Total Request, Maximum Running Instances, Average Response Time and Maximum Response Time.

Here is the data:

My biggest question is how on earth "Map Svc A"with Total Request of 831 at Time 1 has Average response time of under 1 second whereas "Map Svc B" with Total Request of just 31 has max Response Tme of 221 seconds ? At time 4, all  both Map Services A and B are really slow. 

What is going on ? How to read the server stats correctly ?

Here is some graphics to give general idea.

The graphic below shows the Max Running Instances, Total Request and Average Response of ALL Map services at both times, 1 and 4.

The graphic below shows that Service Maximum Running Instances all 0.

Here is the graphic about Total Request of Map Service A and B at two different times:

Here is a graphic about Average Response Time:

Any explanation welcome. I want to understand it better..

Thanks

[HenryLindemann]

Hi @yockee 
Total Request: This is the volume of hits you have e.g. how may views of the map service

Maximum Running Instances: Is the longest time one of these requests took to complete, this can be a long running request if the service enters the que.

Average Response Time: this is just the Average response over all the requests 

The reason for the big discrepancy in time will be because SVC B is probably a complex service compared to SVC A or SVC A can have a cache, for example a boundary of a state will be less complex than a boundary of a neighborhood what we call a cadaster. or SVC A can be a MAP Service and SVC B can be a feature service which is an editable service and takes a lot more time to draw. Or SVC B's data source can be a database in SQL Server and SVC A might be a file on disk called a File Geodatabase.

What you can have a look at is if the service is dynamic or dedicated dynamic pooling is where all the services share the instances normally set at 4 and they start slower but use less RAM, whereas dedicated are faster but consume more RAM. you can also increase the dynamic pooling to a max of your CPU count, and this will increase concurrency.

Around the Cache this you normally build if the service is a static service

Hope that helps.

Kind Regards
Henry

[berniejconnors]

Another thing to consider is that some requests just take longer because they are requesting more data.  For example, a map service that displays civic address points - a request that returns 10 points will be faster than a request that returns 10,000 points.  As an ArcGIS Administrator, it is hard to imagine what the users will attempt to request from your services.  You should be able to get log files of your inbound traffic to examine the requests.  Pay special attention to the requests that take more time.  These logs should ba available from the web server on your web adaptor (not the ArcGIS Server logs).  These would likely be IIS logs or Apache logs.

If you have published ArcGIS web apps (like an Experience Builder or Web App Builder app) you can also use the Chrome Dev tools to look at the requests generated by the web app.  I made the mistake of publishing a Web App Builder app with a poorly configured Search widget.  I configured the search widget to use "LIKE" instead of "=".  Using "LIKE" negates the benefits of the indexes you have built for your attribute data and causes your searches to be slower.  You should also ensure you are only searching agasinst one or two attributes - not all attributes.  Looking at your inbound traffic will really help identify problems.

There are tools in ArcGIS Pro to help you optimize the performance of your map before you publish it as a map service.

If you only have 12 map services, your server should be able to handle publishing all 12 map services as dedicated services.  Your most popular map services should be configured with higher min and max instances.  This will help avoid requests waiting to be processed.  The pooled map service can be saved for your less popular map services.  The stats your are collecting will show you which map services get fewer requests.

Bernie.

[berniejconnors]

Esri's low-code / no-code app builders make it really easy to build apps that look very polished.  But looking polished does not equate to fast and efficient use of your ArcGIS Server services.  You still have to ensure the apps are configured properly or you will have poor performance >> slow apps and busy servers.