Allocation of server resources to caching
ArcGIS Server creates cache tiles using a geoprocessing service named CachingTools. This service is configured for you in the System folder when you create the ArcGIS Server site. The number of instances you allow for the CachingTools service determines how much power your machine can dedicate toward caching jobs.
Additionally, you always need to have at least one instance running of the map, globe, or image service that you are caching. Increasing the number of instances of the map, globe, or image service does not affect how fast tiles are created.
In ArcGIS 10.0 and previous versions, to increase the number of operating system processes working on a caching job, you increased the number of instances of the map or globe service being cached. Beginning at 10.1, you increase the number of instances of the CachingTools geoprocessing service instead.
At any time, you can use Manager to adjust the maximum number of instances of the CachingTools geoprocessing service that you want to make available for working on caching jobs. The minimum and maximum values apply to each individual GIS server; thus, if your maximum is set to a value of 3 and you have four GIS servers in the cluster running the CachingTools service, you could have up to 12 instances of CachingTools running.
This behavior allows you to add and remove GIS servers from the site to increase or reduce the number of resources dedicated to caching. You can add a GIS server even when the caching job is running and it will be detected and assigned tiles to create.
Choosing the number of instances to work on a caching job
When you run a caching job, one instance of the CachingTools service acts as the controller instance. This instance distributes assignments to one or more worker instances. It is the worker instances that actually modify the tiles. In order to ensure at least one controller and one worker instance are available, the maximum number of instances you allow for CachingTools should always be 2 or greater.
Tools such as Manage Map Server Cache Tiles allow you to choose how many instances of CachingTools will be designated as worker instances. If you're not sure what number to enter, take the number of GIS server CPU cores in your cluster and add one to that number. The ideal number of instances may vary based on the nature of the service, but this is an appropriate starting figure for testing.
To figure out the maximum number of instances you can enter, multiply the number of GIS server machines in the CachingTools cluster by the maximum number of instances of CachingTools allowed to run per machine. Then subtract one for the controller instance.
You can choose to divide the available instances of CachingTools among several running jobs. A job might not utilize its maximum number of instances of CachingTools if those instances are being used by other jobs. If a caching job is using all the CachingTools instances, other requested jobs are queued until the first job finishes.
Suppose you want to create a cache and you have three GIS servers in a site with one cluster. Each server allows a maximum of four instances of CachingTools. The maximum number of instances you can dedicate toward any caching job is (3 * 4) - 1, or 11. Manage Map Server Cache Tiles or any other caching tool would not allow you to enter a value higher than this.
If you want to run two simultaneous caching jobs on this site and maintain an evenly distributed load, the number of instances to dedicate to each job is (12 - 2)/2, or 5. In other words, you take the total number of instances available to the site (3 * 4, or 12), then subtract two controller instances, then divide by two jobs.
Allowing for elasticity
It may be that you have configured your site in a cloud environment that can automatically add GIS servers in response to demand. In this case, you might not want to be limited by a fixed maximum number of instances that can work on the job. In this situation, you can enter a value of -1 to indicate that there is no limit on the number of instances that can work on the job. All the available instances of CachingTools will be used for the job, no matter how many GIS servers are added to your site.
Clusters are used in large ArcGIS sites to divide work among subsets of GIS servers. Caching jobs are elastic and spread to all available GIS servers in the cluster on which the CachingTools service is running.
When you configure your site for the first time, there is only one cluster, named default. If you want to constrain your caching jobs to a subset of machines, you should create a new cluster and assign the CachingTools service to run on that cluster. You can then potentially assign your other services to a different cluster so that they are not overrun by processes from the caching job.
You can create a cache for a service that is not running in the same cluster as the CachingTools geoprocessing service. For example, you might have a map service, Spain, that is running on Cluster A and your CachingTools service running on Cluster B. With this configuration, you can still create a cache of Spain.