ArcGIS Server provides the ability, starting at 10.7, to use either shared instances or dedicated instances for each compatible map service published to an ArcGIS Server site from ArcGIS Pro. Prior to 10.7, all services used the model now called dedicated instances. 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.
Shared instances are thus 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.
This topic explains service instances and processes, describes best practices for shared and dedicated instances, and provides steps to set up your service instance settings.
Introduction to 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.
If you have many services on your ArcGIS Server site, and each uses one or more service instances that are always running, your available computer memory could eventually reach its limit. There is also an energy cost for your organization to run service instances, and if you deploy ArcGIS Server on cloud infrastructure, there is a direct monetary cost to each service instance you are running.
Accordingly, it's important for ArcGIS Server administrators to monitor the number of instances their site is running, and to limit running instances when performance is inhibited by memory usage.
Users expect quick results when they interact with your services (including products built atop services, such as web maps and apps). Adequate ArcSOC processes are required to handle the traffic your services receive. However, provisioning more server resources than a service needs wastes computer memory, energy, and money. A good goal for administrators is to pare down the number of running service instances to as many as are needed without affecting performance.
To learn more about active management strategies to optimize ArcGIS Server performance, see Anticipate and accommodate users.
Minimum and maximum service instances
For each service published to your ArcGIS Server site, you can specify a minimum number of dedicated instances running, and a maximum number of instances that can run for the service using ArcGIS Server Manager. For example, if you set this parameter to three instances, there will always be at least three instances running on ArcSOC processes at any given time, even when the service is not being used.
If you set the minimum number of instances to zero, the service will not have any instances running if it is not being used. This saves memory usage by powering down an unused service, but there's a drawback: The next time a user sends a request to the service, they will experience a delayed response. This cold start while ArcGIS Server powers up an instance to handle the service request may be noticeable to the user making the request.
Shared and dedicated instances
The shared instance pool, introduced at ArcGIS Server 10.7, is always running on each machine in your site. Any map service published from ArcGIS Pro can be configured to use the shared instance pool.
Tip:
To determine which application a map service has been published from, see step 3 in Configure the instance type for a service below.
When you configure shared instances, services that use this pool no longer incur resource usage costs when they are not handling requests, and there is no cold start drawback.
The following restrictions limit what services can use the shared instance pool:
- 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.
With the introduction of shared instances, there is now a distinction from dedicated instances, which only run a specific service until they are powered down. Dedicated instances are still a valid option for administrators, particularly with high-traffic services. This is both to ensure optimal performance for these services by providing dedicated server resources for them, and to prevent high-traffic services from using all the processes in your pool.
Note:
When you upgrade ArcGIS Server to 10.7 from an earlier version, your minimum instances settings for services will not change, but a default pool of ArcSOC processes will be set aside for shared instances. If you want to configure shared instances for some or all of your services, you can do so after upgrading.
When to use each instance type
Neither instance type is uniformly best for all of your map services. As a server site administrator, you can decide which instance pool each service published to your site should use.
You can configure shared instances for some of your services while choosing to give other services their own dedicated ArcSOC processes. You might choose this split configuration if you know some of your services receive continuous requests, while others are used less frequently. If all your services receive requests only occasionally, consider configuring shared instances for all services to conserve memory usage.
Tip:
Usage patterns often change, so as you monitor your site, adjust the instance type settings as you see fit, based on traffic and server performance.
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.
By contrast, the dedicated instance pool remains the best option for services such as these:
- Services you contract under a service-level agreement.
- Services that receive heavy use (nearly constant requests or compute-extensive requests).
- Services for which you have set the minimum dedicated instances to a high number.
- All services that are not compatible with the shared instance pool, as defined above.
Configure default service instance settings
Administrators can specify a default instance type setting for compatible map services published from ArcGIS Pro. When such a service is published to your server, it will use the default instance type. You can then change the instance type for the individual service using the steps in the next section.
If you select shared instances to be the default instance type for your services, the setting will only apply to compatible map services. Services that cannot use the shared instance pool will continue to use their dedicated instance pool.
Changing the default instance type setting will only affect services published in the future. It will not change the instance type settings for existing services.
Note:
The shared instance pool consumes a small amount of memory based on the number of services that receive requests. For a shared instance pool that handles requests for a large number of services, you will see memory rise gradually as more services receive requests. Memory consumption will level off after 50 or more services have received requests within a single recycle period.
Follow these steps to specify the default instance type or the number of instances in the shared instance pool.
- Sign in to ArcGIS Server Manager as an administrator. The URL is formatted https://webadaptor.domain.com/arcgis/manager.
- Browse to Site > Settings. You'll access these settings from the Pooling page.
- To change the default instance type for compatible map services, click the edit button for Default Instance Type. Select the instance type you want to have be the default setting:
- Select Dedicated instances if you anticipate that most of your services will receive frequent traffic, or if you will not have enough services running in your server site to present a significant load on machine memory.
- Select Shared instances if you publish many services that only receive infrequent requests, or if you are concerned about additional services being published that will strain your memory resources.
- Confirm your selection by clicking Apply.
- To change the number of service instances running in the shared instance pool, click the edit button for Shared Instance Settings.
If your site will have a mix of services using shared instances and dedicated instances, set the number of instances in the shared pool as equal to the number of CPU cores on the individual machines in your ArcGIS Server site (for example, if you're using 4-core machines, set the number of shared instances to 4). If you will be configuring most or all of your services to use the shared instance pool, consider increasing the instance number to be double the number of cores (if using 4-core machines, set the number of shared instances to 8).
These suggestions are meant as starting points. You should monitor your ArcGIS Server site to ensure that you make the most of your available resources, and to ensure the site is not overloaded by traffic. The optimal number of instances in the pool depends on the amount of traffic serviced by the shared pool, the amount and type of data being served, and the amount of available computing resources.
- Confirm your selection by clicking Apply.
Configure the instance type for a service
Administrators can also specify the instance type for an individual service after it has been published, overriding the default setting. Follow these steps to change the instance type for an individual service. To use the shared instance pool, a map service must have been published from ArcGIS Pro and meet the other requirements as given above.
- Share a web layer (as a map image layer) or a web map from ArcGIS Pro to your ArcGIS Enterprise portal. A map service will be created on your federated ArcGIS Server.
Note:
Only certain capabilities of map services—feature access, WFS, WMS, and KML—can be enabled on a map service that uses the shared instance pool.
- Sign in to ArcGIS Server Manager as an administrator. The URL is formatted https://webadaptor.domain.com/arcgis/manager.
- Locate the map service and click it.
The Editing page appears. On the General tab, under Original Document, an Authoring Application property indicates that this map service was published from ArcGIS Pro.
- On the left side of the page, click the Pooling tab.
This tab allows you to specify the range of dedicated instances for the services, set service timeout properties, and designate whether the service uses dedicated instances or shared instances.
- Click the Shared instance pool option.
- When you choose this option, some map service capabilities (on the Capabilities tab) will be made unavailable. If you are unable to select the Shared instance pool option, ensure that you do not have any unsupported capabilities enabled on the map service. See the note in step 1.
- When the shared instance pool is turned on for a service, the Specify Number of Instances section (for dedicated instance pools) becomes unavailable.
- When you are ready, click Save and restart. When the instance pool option has been changed on a map service, the service must restart.
You can change the instance pool used by a map service at any time; you may need to do so when service traffic patterns change.