The power of ArcGIS Server lies in its ability to provide GIS functionality to many users in different places. When planning your ArcGIS Server, determine how many users will use your system and how much hardware you need to support that number of users. Other factors, such as whether 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.
Adjust the number of machines in a site
An ArcGIS Server site is an assemblage of one or more machines participating on equal terms. In times of high processing loads, an ArcGIS Server machine generally reaches full CPU utilization before the web server; therefore, determining how many ArcGIS Server machines to deploy is an important decision for accommodating users.
Once your system is up and running, use the logs and server statistics to evaluate how well your server performs. Also, use operating system tools, such as Windows Performance Monitor, to evaluate how busy your server is when accommodating requests. Finally, some third-party tools and services may be available to monitor system performance. Amazon Cloud Watch, in the Amazon EC2 platform, is an example of a web service that monitors system performance in a cloud environment.
If you find that normal requests to ArcGIS Server time out during peak system loads and your CPU utilization approaches 100 percent for an extended period of time, your system may benefit from additional machines at the ArcGIS Server tier. Add new machines either manually or through an automated process using virtual machines. For example, you can create a script that adds a new ArcGIS Server machine when the CPU exceeds 70 percent utilization for more than 15 minutes.
Some procedures, such as map caching or geoprocessing, can take a relatively large amount of CPU resources. If you can anticipate when these jobs perform, you can create more ArcGIS Server machines temporarily and destroy them when the job finishes. In these scenarios, virtual machines and cloud computing platforms are very convenient because the additional hardware can be acquired quickly and released immediately after use.
Understand service instances
When a request is made to a service in your ArcGIS Server site, such as to pan a map or navigate to an address, it is handled by an instance of the published service running on a server machine. Service instances are powered by Esri proprietary server processes called ArcSOC processes. Each ArcSOC process takes a certain amount of your machine's memory to run.
Shared instances are recommended for services that receive infrequent requests, particularly when the server site hosts many services. Dedicated instances, on the other hand, make a service always available to handle requests using one or more server processes, and are ideal to use for services that receive constant or particularly compute-intensive requests.
The shared instance pool is suitable for compatible map services such as these:
- Services that are infrequently used. This will vary by deployment, but for most deployments, this means fewer than one service request per minute on average.
- Services for which you have already set the minimum dedicated instances to zero.
- Most cached map services.
ArcGIS Server provides the ability to use either shared instances or dedicated instances for each compatible map service published to an ArcGIS Server site from ArcGIS Pro. Using shared instances conserves memory usage by pooling several active server processes for use by multiple services. By doing so, it reduces the memory usage of services that are not actively handling requests.
Choose an instance type
Shared instances are recommended for services that receive infrequent requests, particularly when the server site hosts many services. Dedicated instances, on the other hand, make a service always available to handle requests using one or more server processes, and are ideal to use for services that receive constant or particularly compute-intensive requests.
Administrators can both choose a default instance type (whether compatible map services should initially use shared or dedicated instances) and change the instance type for an individual service at any time. Base these decisions on traffic volume—either to accommodate current traffic or to prepare for anticipated changes in traffic.
Not all services can use the shared instance pool. The following restrictions apply:
- Only map services published from ArcGIS Pro can be configured to use the shared instance pool. Other service types, such as geoprocessing services, are not supported.
- Only certain capabilities of map services—feature access, WFS, WMS, and KML—can be enabled. Turn off all other capabilities before continuing.
- Services that have custom server object extensions (SOEs) or server object interceptors (SOIs) cannot use shared instances.
- Services published from ArcMap cannot use shared instances.
- Cached map services published from ArcGIS Pro that meet the above requirements can use shared instances.
The shared instance pool is suitable for compatible map services such as these:
- Services that are infrequently used. This will vary by deployment, but for most deployments, this means fewer than one service request per minute on average.
- Services for which you have already set the minimum dedicated instances to zero.
- Most cached map services.
Adjust dedicated instance pools
When a service is using dedicated instances, you can adjust the minimum and maximum number of instances allowed per machine. These parameters can help your site's services accommodate swings in traffic volume.
The maximum number of instances property represents the greatest number of instances of that particular service running on any given ArcGIS Server machine. As an administrator, determine how many instances of a service configuration satisfies the expected user demand at an acceptable level of performance. This is a compound 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 instances you need in a service configuration is best determined by monitoring your server over time. If your client wait times are long or requests are timing out, you may need to adjust the number of available instances or how your application uses those instances. Once you determine the number of instances that support your clients, divide it by the number of ArcGIS Server machines in your deployment and set the maximum number of instances for the service configuration to the resulting number. For example, if you need a maximum of ten instances of a service able to simultaneously handle its requests, and you have two available ArcGIS Server machines, set the maximum number of instances to five.
The minimum number of instances property represents the number of dedicated instances that are already created and available for use for a service on each ArcGIS Server machine. If you doubt that many users will concurrently use a service, consider lowering its minimum number of instances.
You can even set the minimum at zero instances. However, this causes a short delay in performance when a service without any active instances next receives a request. This lag time is called a "cold start."
Consider the length of time users 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.
Use the logs and server statistics to determine whether excessive requests are causing time-outs and if services are being used beyond their maximum usage time. Use Server Manager to adjust the number of available service instances and the maximum wait and usage times for a service.