Tuning and configuring services

ArcGIS for Desktop makes it easy to publish services right away because it sets many of the default service properties for you; however, if hundreds or thousands of users will be accessing your services, you'll want to change the default service property values to best accommodate your deployment. This topic provides an overview of some of the properties and techniques that you can use to best configure your services.

Pooling

All services published with ArcGIS 10.1 for Server, are pooled. This means that instances of the service can be shared between multiple application sessions.

An application that uses an instance of a pooled service only uses it for the amount of time it takes to complete one request (for example, to draw a map or geocode an address). After the request is completed, the application releases its reference to the service and returns it directly to the available pool of instances.

Recycling

Service recycling allows services that have become unusable to be destroyed and replaced with fresh services; recycling also reclaims resources taken up by stale services.

Services are typically shared between multiple applications and users of those applications. Through reuse, a number of things can happen to a service to make it unavailable for use by applications. For example, an application may incorrectly modify a service's state, or an application may incorrectly hold a reference to a service, making it unavailable to other applications or sessions. In some cases, services may become corrupted and unusable. Recycling allows you to keep the pool of services fresh and cycle out stale or unusable services.

During recycling, the server destroys, then re-creates, each instance in the service configuration. Recycling occurs as a background process on the server. Although you will not see anything on your screen notifying you that recycling is occurring, you can see the events associated with recycling in the log files.

Recycling destroys and re-creates all running instances of a service, whether or not those instances are above the minimum specified. To periodically return the number of running instances to the minimum specified, the service must be stopped and restarted. A good way to automate this process is to create a Python, shell, or Windows batch script that executes a custom ArcGIS Server administrative API command line executable file. This custom executable file would take the server name, service name, service type, and whether the service should be started or stopped as command line arguments.

The time between recycling events is the recycling interval. The default recycling interval is 24 hours, which you can change on the Service Editor dialog box. You can also choose the time that the configuration is initially recycled. From that time forward, recycling will occur each time the recycling interval is reached.

Services are recycled one instance at a time to ensure that instances remain available and to spread out the performance hits caused by creating a new instance of each service. Recycling occurs in random order; however, instances of services in use by clients are not recycled until released. In this way, recycling occurs without interrupting the user of a service.

If there are not enough services available during recycling, a request is queued until an instance becomes available. If the service's maximum wait time is reached during this period, the logs record the same message that they normally would.

Isolation

When you create a service, you specify the minimum and maximum number of instances you want to make available. These instances run on the container machines within processes. The isolation level determines whether these instances run in separate processes or shared processes.

With high isolation, each instance runs in its own process. If something causes the process to fail, it will only affect the single instance running in it.

High isolation services
Services with high isolation running in dedicated processes on the GIS server

In contrast, low isolation allows multiple instances of a service configuration to share a single process, thus allowing one process to handle multiple concurrent, independent requests. This is often referred to as multithreading.

Low isolation services

With low isolation, a default of 8 instances and a maximum of 24 instances of the same service configuration can share a process. You can set the value for Instances per process on the Processes tab of the Service Editor. When this number of instances of a particular service is created, the server starts an additional process for the next group of instances, and so on. As instances are created and destroyed, they vacate and fill spaces in those running processes.

The advantage of low isolation is that it increases the number of concurrent instances supported by a single process. Using low isolation can use slightly less memory on your server. However, this improvement comes with some risk. If a process experiences a shutdown or crash, all instances sharing the process are destroyed. It is strongly recommended that you use high isolation.

Checking for invalid data connections

When a service instance sits idle, it can be difficult for a server administrator to determine if connections to the source data are being successfully maintained. ArcGIS Server has built-in mechanisms to check for invalid connections to ArcSDE geodatabases. These checks prevent your service from appearing unresponsive after a connection to ArcSDE is dropped or interrupted.

You can enable the data connection validity checks by opening the Processes tab of the Service Editor dialog box in either ArcGIS for Desktop or Manager and checking the check box Periodically check and repair data connections for idle instances. You also need to specify an interval in minutes at which service connections will be automatically validated (and repaired if needed). The default of 30 minutes is usually appropriate.

Enabling these checks may also help you if firewalls are closing ports to ArcSDE after your services sit idle for a certain period of time. In this situation, your choice of time interval may be influenced by firewall timeout settings.

Timeouts

Understanding the various available service timeout values can help you keep your services working and available. These values are available on the Pooling tab of the Service Editor dialog box.

Once a client gets a reference to a service, it uses the service for a certain period of time before releasing it. The amount of time between when a client gets a reference to a service and when it releases it is the usage time. To ensure that clients don't hold references to services for too long (that is, they don't correctly release services), each service has a maximum time a client can use a service. If a client holds on to a service for longer than the maximum usage time, the service is automatically released and the client loses its reference to the service.

Dive-inDive-in:

When you create a new service, the default value for the maximum usage time is 600 seconds (10 minutes). However, in the pregenerated PublishingTools service that comes with each ArcGIS Server site, the maximum usage time has been set at 3600 seconds (60 minutes). This is to accommodate publishing jobs that have lots of data copied to the server.

Maximum usage time also protects services from being used to do larger volumes of work than the administrator intended. For example, a service that is used by an application to perform geodatabase checkouts might have a maximum usage time of 10 minutes. In contrast, a service that is used by applications that only draw maps might have a maximum usage time of 1 minute.

When the maximum number of instances of a service is in use, a client requesting a service is queued until another client releases one of the services. The amount of time it takes between a client requesting a service and getting a service is the wait time. Each service has a maximum time a client will wait to get a service. If a client's wait time exceeds the maximum wait time for a service, the request times out.

A third timeout dictates the maximum time an idle instance can be kept running. When services go out of use, they are kept running on the server until another client needs the instance. A running instance that is not in use still consumes some memory on the server. You can minimize your number of running services and therefore conserve memory by shortening this idle timeout, the default of which is 1,800 seconds (30 minutes). The disadvantage of a short idle timeout is that when all running services time out, subsequent clients need to wait for new instances to be created.

When services are created in the GIS server, either as a result of the server starting or in response to a request for a server by a client, the time it takes to initialize the service is referred to as its creation time. The GIS server maintains a startup timeout that dictates the amount of time that can elapse on a startup attempt before the GIS server assumes its startup is hanging and cancels the creation of the service.

The GIS server maintains statistics both in memory and in its logs about wait time, usage time, and other events that occur within the server. The server administrator can use these statistics to determine if, for example, the wait time for a service is high, which may indicate a need to increase the maximum number of instances for that service.

Limiting what users can do with a service

To make it easy to control how your web services are used, each type of service has a set of allowed operations. Each operation consists of a set of methods that can be enabled or disabled as a group. Clients of the web service can only call the methods of the operations that have been allowed.

Suppose you wanted to allow consumers of a mapping web service to draw the map but not to query the data sources of the map's layers. You would then need to disable the Query operation and ensure that the Map operation is allowed.

Feature services are of special interest in this discussion because they are used for performing web-based editing of GIS data. Feature services have an additional set of operations that can be used to restrict editing functionality: Query, Create, Update, and Delete. You can enable or disable these in the Feature Access tab of the Service Editor dialog box in ArcGIS for Desktop. You can also prevent users from editing features they did not originally create by enforcing ownership-based access control.

The following tables show methods that are enabled when you allow operations on various service types:

Map service operations

The default allowed operations for map services are Map, Query, and Data.

Map

Query

Data

GetDocumentInfo

Identify

Find

GetLegendInfo

QueryFeatureCount

QueryData

GetMapCount

QueryFeatureCount2

QueryFeatureData

GetMapName

QueryFeatureIDs

QueryFeatureData2

GetDefaultMapName

QueryFeatureIDs2

QueryAttachmentInfos

GetServerInfo

QueryHyperlinks

QueryAttachmentInfos2

GetSupportedImageReturnType

QueryHTMLPopups

QueryAttachmentData

ExportMapImage

QueryHTMLPopups2

QueryAttachmentData2

IsFixedScaleMap

GetSQLSyntaxInfo

QueryRelatedRecords

ToMapPoints

QueryRelatedRecords2

FromMapPoints

QueryRasterValue

HasSingleFusedMapCache

QueryRasterValue2

GetTileCacheInfo

GetMapTile

HasLayerCache

GetLayerTile

GetVirtualCacheDirectory

GetCacheName

ComputeScale

ComputeDistance

ExportScaleBar

GetCacheDescriptionInfo

GetCacheControlInfo

GetCacheStorageInfo

GetDefaultLayerDrawingDescriptions

GetMapTableSubtypeInfos

GetMapTableSubtypeInfos2

GetServiceConfigurationInfo

Geocode service operations

The default allowed operations for geocode services are Geocode and Reverse Geocode.

Geocode

Reverse Geocode

GeocodeAddress

ReverseGeocode

GeocodeAddresses

StandardizeAddress

FindAddressCandidates

GetAddressFields

GetCandidateFields

GetIntersectionCandidateFields

GetStandardizedFields

GetStandardizedIntersectionFields

GetResultFields

GetDefaultInputFieldMapping

GetLocatorProperties

Geodata service operations

The default allowed operations for geodata services are Query, Extraction, and Replication. These enable all the supported methods for querying data, extracting data, synchronizing data, data changes, message acknowledgment, and schema.

Query

Extraction

Replication

Get_Versions

ExpandReplicaDatasets

CreateReplica

Get_DefaultWorkingVersion

ExtractData

ExportAcknowledgement

Get_DataElements

ExportReplicaDataChanges

Get_MaxRecordCount

ImportAcknowledgement

TableSearch

ImportReplicaDataChanges

GetNextResultPortion

ReExportReplicaDataChanges

Get_Replicas

UnregisterReplica

Get_WrappedWorkspaceType

ImportData

Globe service operations

The default allowed operations for globe services are Globe, Animation, and Query. Unlike with map services, the Query operation covers both Identify and Find.

Globe

Animation

Query

Get_Version

Get_Animation

Identify

Get_LayerCount

Find

Get_LayerInfos

Get_LegendInfos

Get_Config

Get_MQT

Get_Configuration

Get_Tile

Get_Symbols

Get_Textures

Get_VirtualCacheDirectory

Image service operations

If you published the image service from a mosaic dataset, all the capabilities are enabled by default. If you published from some other source, such as a raster dataset, a compiled image service definition, or a layer file, only the Image and Metadata capabilities are applicable and enabled.

Image

Catalog

Download

Metadata

Pixels

ExportImage

Fields

Download

Metadata

GetNativePixelBlock

ExportMapImage

GetCatalogItemCount

GetFile

GetRasterMetadata

GetPixelBlock

GenerateServiceInfo

GetCatalogItemIDs

GetImage

GetCatalogItems

Identify

GetNativeRasterInfo

ServiceInfo

GetRasterInfo

Version

GetThumbnail

12/18/2014