Interpreting server statistics
When you add a service to the server, you set some initial values for its configuration. As clients begin accessing the service, you can monitor its performance by examining its statistics. You can review statistics for your entire ArcGIS server as well as each individual service. You can examine how many requests get processed per unit of time, what the average wait time is for a client, and how many requests timed out and didn't get a response back from the server.
How to display server statistics
Statistics for the ArcGIS Server as a whole and for individual services can be found on the Charts panel in ArcGIS Server Manager. In Manager, open the GIS Server tab and click the Charts panel. The types of statistics that you can view are the following:
- Request throughput
- Request totals
- Timeout rates
- Error rates
- Usage and wait times
- Utilization
Displaying statistics for the GIS server
- On the ArcGIS Server Charts page, select the type of statistical chart you would like to see from the drop-down list.
- Click Generate Chart.
Using statistics to make decisions
Statistics can help you proactively monitor your server and its service configurations. A careful analysis of server statistics may help you catch a potential problem before it affects a large number of your server's clients. The following examples suggest actions you can take to remedy troubling statistics.
High usage time or too many usage timeouts
Usage timeouts occur when a client holds on to a server context beyond the maximum allowable usage time. This maximum usage time is a property of the service, so you can change it if necessary. The default value is 600 seconds.
If a service is experiencing too many usage timeouts, it may mean that the service is consistently having a problem completing a certain task. If this is the case, check your service and its associated data and ensure that these are configured correctly. If the service is working fine, you might want to increase the maximum allowable usage time for the service.
To keep usage time down, ensure that your applications are designed to make efficient use of service pooling models and server contexts. Developers should ensure that their code releases unused server contexts as soon as possible to make them available to other clients.
You should avoid using a nonpooled service when a pooled service will suffice. Nonpooled services should only be used in stateful applications.
High wait time or too many wait timeouts
Wait time is a combination of the time a client spends waiting in a queue and the time the server takes to create a service. Wait time is one of the more interesting statistics, because it is a measure of how fast a client application feels.
Wait time is related to usage time, because if usage time is high, clients will potentially have to wait longer to get a server context. If the client has to wait too long, a wait timeout will occur.
If the average wait time for a service approaches the service's maximum allowable wait time, you're in danger of experiencing excessive timeouts. If you feel the wait time is reasonable, you can avoid the timeouts by increasing the maximum allowable wait time. If you want to lower the wait time, consider creating more instances of the service.
At some point, increasing the number of instances won't improve performance, because you've reached the capacity of your server machines. To alleviate this issue, you can either reduce the number of instances allocated to other server services or add new server object container (SOC) machines to your system.