Interpreting server statistics
Interpreting server statistics |
|
| Release 9.3 |
|
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 GIS 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.
Statistics for the GIS server as a whole and for individual services can be found on the GIS Server Charts page in Manger. Browse to the GIS Server page and click on the Charts link. The types of statistics that you can view are as follows:
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.
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 so as to make them available to other clients.
You should avoid using a non-pooled service when a pooled service will suffice. Non-pooled services should only be used in stateful applications. In some situations, it's even possible to use a pooled service in a stateful way, thus avoiding the need to tie up server contexts with a non-pooled service.
If you are using MapServer or GlobeServer services, you can also cut usage time by following the tips for preparing map and globe documents found in 'Guidelines for preparing data.' One important example of these tips is to use simple, scale-dependent renderers for features and labels. This cuts drawing time, thereby lowering service usage time.
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.