ArcGIS Server: It is all about efficiency
It is all about efficiency
ArcGIS Server can be considered as the engine of our ArcGIS Enterprise car or a GIS office in a box for example. Like any office, the balancing act of numbers of staff vs. demand vs. resources is an ongoing calculus. And that is true in our ArcGIS office in a box too. Most GIS offices are limited in staff capacity by factors like workstations available, network bandwidth, or licenses of essential software. If we run out of desks and computers that analysts can use, we cannot add any more analysts to the office. If all the analysts are working on some tasks, we cannot ask for a new task to be started. Even if we expand the space and add infrastructure, we cannot use that increased capacity if we do not purchase more licenses of ArcGIS Pro. With ArcGIS Server we can face the same challenges and limits. So, it is vitally important to configure the GIS web services (services) running in ArcGIS Server to efficiently use the finite resources available to it, while also ensuring the best throughput and speed for the system.
Every non-hosted service in ArcGIS Server has a set of configuration options that can be defined at publication time in ArcGIS Pro or after publication with the administrative web application ArcGIS Server Manager. A service can exist in ArcGIS Server in many states. First it is published. This means a service definition file has been created, and it exists within the Server directory in a subfolder called arcgisinput, by default this is found at C:\arcgisserver\directories\arcgissystem\arcgisinput. Second the service can be running or stopped. By default, published services are started when published, although services can be stopped too. When a service is started and running it is “advertised” in another web application the ArcGIS Server Services Directory. Here admins, publishers, and developers find useful properties and supported operations that can be used to inspect and use the services.
Another result of starting a service in ArcGIS Server is that the manager components of our “office” will start the minimum number of instances set for the service, by default this is one instance. Technically an instance of a service is a single processing unit, typically manifested as an ArcSOC.exe process running in the operating system of the host computer. You can think of an instance of a service as an analyst sitting at a desk with the required ArcGIS Pro project available to them that can respond to requests for defined capabilities of the advertised GIS resource. Notice the number of instances running is not directly related to the number of applications nor people “using” the service. In this case the instance is running and just waiting for a request. This is called the idle state of the instance.
The minimum number of instances defines how many instances of the service are started when the service is started. This can be set to any number including zero. But don’t go crazy with this number, remember the GIS server has finite resources available to it and there are most likely other services running that need to use those resources to support their instances too. But that’s just the minimum. There is also a maximum number of instances that can be instantiated too. This maximum can be greater than or equal to the minimum number of instances. By default, this number is two. So, by default when a service is published to ArcGIS Server the greatest number of virtual analysts that can ever exist to respond to requests to that service is two. Is that going to be enough? Most likely not. Especially if this is a medium to high demand service. But again, remember that although you can set this maximum to any number, you can easily overwhelm your system by allowing more instances to be created than the total system can handle. Also, there will be other services running in ArcGIS Server with their own instances that need to consume those finite resources too.
Up until ArcGIS 10.7, this was the only way to control the number of analysts (instances) that existed in our GIS office (ArcGIS Server). All the instances that existed in ArcGIS Server were defined for each service separately and were only able to respond to requests for that service. We can think of this as if each analyst in our GIS office can only open one project at a time in ArcGIS Pro and the project can only have one map, or scene, or model, or other single GIS resource in it that the analyst can interact with to respond to requests. These are referred to as dedicated instances.
Then at ArcGIS 10.7, we introduced a new concept of the shared instance pool. The instances in this pool can respond to requests to any service assigned to it, with certain limits on which types of services can be assigned to it. You can consider this shared instance pool as some number of analysts in our office that have a copy of the same project open in ArcGIS Pro that has many maps (one for each service assigned to the pool) available in it. The benefit this brings is that the low demand services have instances already running to support them quickly, but the computer resources are not being wasted on instances that are not in use.
One last consideration when talking about instances of a service is that not all the services our users have access to are managed as separate services in ArcGIS Server. For example, when you publish a map service there is a map service made available in Server Manager for managing properties like the min/max number of instances. That map service also has its own URL, or end point, that clients communicate through. But the map service object in ArcGIS Server Manager also has a capabilities property. Through this property additional capabilities can be enabled like the feature access capability. Enabling this will cause ArcGIS Server to create another URL for a feature service. But this feature service, and any other services enabled via a capability, does not instantiate its own instances. The original instances created for the associated map service also support the feature service.
Through this article we have seen that there are many ways that we can control and manage GIS web services to affect the performance that is provided by ArcGIS Server. But ArcGIS Server is just one part of the process of creating, managing, and sharing GIS resources. In most cases the decisions we make in storing the GIS data or authoring the resources will have a greater affect than these options. In Esri’s instructor led training curriculum we discuss and implement many content specific optimization techniques in our course Sharing Content to ArcGIS Enterprise.