Anticipating and accommodating users
Anticipating and accommodating users |
|
| Release 9.3 |
|
The power of ArcGIS Server lies in its ability to provide GIS functionality to many users in different places. When planning your GIS server, you should try to determine how many users will be using your system and how much hardware you will need to support that number of users. Other factors, such as whether or not the usage is likely to come in spurts, should affect your decisions. If you don't have the option to add more hardware, you may be able to accommodate more users by adjusting your service configurations.
The server does its GIS work in the server object container (SOC) machines. In times of high processing loads, the SOC generally reaches full CPU utilization before the server object manager (SOM) or Web server; therefore, determining how many SOC machines to deploy is an important decision for accommodating users.
To choose the number of SOC machines you need, consider the maximum number of users that will need to be doing something with a service at the same time. Generally, a SOC CPU can support four concurrently active service instances. That means that up to four users can be doing processing on services at one time. Services that are running but not in use should not be included in this count. ArcGIS Server developers should always include code to release server contexts as soon as the GIS operation finishes.
This figure is only provided as a starting point, and it may vary depending on the complexity of the operations that users will be performing on your server and the data they will be working with. Once your system is up and running, you can use the log files and server statistics to help you further size and tune your system. If you find that normal requests to the SOC are timing out during peak system loads and your CPU utilization is reaching 100 percent, your system could probably benefit from additional CPUs at the SOC tier.
Before you test or draw conclusions about your server's performance under heavy loads, make sure you've configured your server to avoid per-request impersonation for web services. Loads of over 25 concurrent requests per second or more may cause the Local Security Authority Subsystem Service (lsass.exe) to become overworked, resulting in severe performance degradation. ESRI Knowledge Base Articles 32620 (Windows Server 2003) or 32622 (Windows XP) explain how to work around this situation.
If you need more detailed guidelines for sizing your system, consult the ESRI System Design Strategies white paper at http://www.esri.com/systemdesign.
If adding hardware to your system is not an option, you may still be able to accommodate more users by wisely configuring your service properties.
For example, all services have a maximum number of instances property, which represents the greatest number of instances of the service that can run at one time. As an administrator, you should try to determine how many instances of a service configuration will satisfy the expected user demand at an acceptable level of performance. This is a complex assessment of the average usage time of a service by a client, the number of expected clients, the frequency of client requests, and the intensity of processing required per request.
The number of services you need in a configuration is probably best determined by trial and error; if your client wait times are long or requests are timing out, you may need to adjust the number of available services or how your application uses those services. Once you determine the number of services that will support your clients, you should set the maximum number of instances for this configuration to that number. This will allow you to use the remaining resources of your system for other service configurations and the clients they support.
Services also have a minimum number of instances property. This represents the number of services that are already created and available for use. If you doubt that many users will be concurrently using a pooled service, consider lowering its minimum number of instances. You can even set the minimum at zero instances if you choose.
Sometimes, external events encourage the use of one particular service. For example, an emergency management application might experience a sudden increase in requests for a certain service during a natural disaster. To optimize ArcGIS Server utilization, it may make sense to increase the maximum number of instances of that service to consume all available server resources. That way, the service can take advantage of the total configuration. ArcGIS Server provides pool shrinking abilities that automatically decrease the number of instances of less-popular service configurations in favor of more popular configurations.
Learn more about pool shrinking.
You should also consider the length of time users will spend using your services. Some requests to the server are more work-intensive than others. A large number of light requests for services may not bog down the server as much as a smaller number of work intensive requests. Each service has a maximum wait time property and a maximum usage time property. If users' requests for services are repeatedly timing out, consider increasing the maximum wait time or the number of available instances of the service.
You can use the log files and server statistics to determine if excessive requests are causing timeouts and if services are getting used beyond their maximum usage time. You can use Manager or ArcCatalog to adjust the number of available services and the maximum usage time for a service.