Use the Pooling page to specify the minimum and maximum number of instances of the geoprocessing service that can run on the server at any one time. Because of the way the server shares these instances among clients, it may be that the number of clients you can support is greater than your number of running instances. For more information about pooling, see the topic Tuning and configuring services. For general tips of setting pooling properties, see Anticipating and accommodating users.
If your GIS Server participates in a cluster with more than one machine, note that the minimum and maximum number of instances is for each machine, not the entire cluster. A cluster of three machines, with a maximum number of instances set to five, would create a service with a total maximum of fifteen, or five per machine.
The maximum time a client can use a service
The maximum time, in seconds, that a service can be used. You may need to increase the default of 600 seconds (10 minutes) for long-running geoprocessing tasks. Alternatively, you may need to reduce this time to ensure a client will not abuse your services.
The maximum time a client will wait to get a service
The maximum time, in seconds, that a client will wait to connect with an instance before timing out. When all instances are busy processing requests, subsequent requests are queued. If this time-out elapses before an instance becomes available, the task will fail. The default is 60 seconds (1 minute).
The maximum time an idle instance can be kept running
The maximum time, in seconds, that an instance will continue to be active before pool shrinking occurs. Any instances above the minimum number of instances that have not been used will be shut down once the idle maximum time value has elapsed.
Use the Processes page to specify how the geoprocessing service will run on the server. The topic Tuning and configuring services gives a high-level overview of the considerations you should take into account when setting isolation and determining recycling intervals.