ArcGIS Server Banner

Performance tips for geoprocessing services

Performance tips for geoprocessing services

Release 9.3 E-mail This TopicPrintable VersionGive Us feedback
Note: This topic was updated for 9.3.1.

Geoprocessing services need to be fast and efficient. Clients want and expect fast service. Since ArcGIS Server can be servicing multiple clients at once, inefficient services can overload your server. The more efficient your services, the more clients can be serviced with the same computing resources.

Below are tips and techniques to increase the performance of your services. In general, techniques are presented in order—those that offer larger performance boost are presented first. The last few tips can shave a few tenths of a second off your execution time, which may be needed for some tasks.

Use local job directories

If your ArcGIS Server configuration has multiple machines, you will want to set up local job directories on each machine. This will significantly improve execution time. Setting up local job directories is a system administrator task.

Learn more about the local jobs directory

Use local paths to data and resources

If possible, data used by your service should be stored on the machine executing the service and not distributed across the LAN. Reading data across the LAN is slower than reading from a local disk. Performance numbers vary, but a rule of thumb is that transferring data across a LAN takes twice as long as using local disk.

Write data to memory

You can write intermediate data to memory. Writing data to memory is faster than writing data to disk. You can also write output data to memory as long as you are not using a result map service. You cannot write rasters to memory.

Learn more about writing data to memory

Use ESRI Grid raster format

ArcGIS supports many different raster data formats. Any tool that operates on raster data first transforms the raster data into ESRI's native GRID format. If your task uses raster data, the raster data should be stored in GRID format so that all model processes operate on GRIDs. (You can use the Raster To Other Format tool or Copy Raster tool to convert any raster to the GRID format.) If your task must output a raster in a particular format, do the conversion from GRID to the output format as the last step of your model.

If you cannot store your raster data in GRID format, then you may want to try using the Copy Raster tool within your model or script to copy a portion of your raster to GRID format, then process the copied portion. To copy a portion of a raster, use the Copy Raster tool and set the geoprocessing output extent environment. Only the cells that fall within the extent will be copied.

What is raster data?

About the ESRI Grid format

About analyzing raster data

Performance tuning for displaying raster data

Use layers from a source map document

If your service uses a source map document, your models and scripts can use layers from the source map document. A layer references a dataset on disk, and some layers cache properties about the dataset. This is particularly true for network dataset layers, as shown in GP Service example: Drivetime polygons. By using a network dataset layer instead of the dataset, there is a performance advantage because ArcMap opens the dataset once, caches basic properties of the dataset, and keeps the dataset open. When the model executes, the dataset does not have to be reopened since the source map document already has it opened—a performance boost.

Avoid unneeded coordinate transformations

See Spatial reference considerations for geoprocessing services for more information.

Add attribute indexes

If your task is selecting data using attribute queries, create an attribute index for each attribute used in queries. You can use the Add Attribute Index tool. You only need to create the index once and you do so outside of your model or script.

Add spatial indexes

If your model or script does spatial queries on shapefiles, create a spatial index for the shapefile using the Add Spatial Index tool. If you are using geodatabase feature classes, spatial indexes are automatically created and maintained for you. In some circumstances, recalculating a spatial index may improve performance, as described in Setting spatial indexes.

Preprocess data used by your tasks

Geoprocessing services are intended to be focused applications for providing answers to specific spatial queries posed by Web clients. Because tasks tend to be specific queries on known data, there is usually an opportunity to preprocess data to optimize the query. For example, adding an attribute or spatial index is a simple preprocess; it only needs to be done once, outside of your task.

Here are some examples of preprocessing from the geoprocessing service examples provided with the tutorial data.

Write data to shapefiles

Writing data to shapefiles is a bit faster than writing to other formats (but writing data to memory, described above, is the fastest). However, there are some severe limitations with shapefiles, such as 10 character field names, no support for null values, and limited support for date/time, to name a few. These limitations can break your model or script. See Geoprocessing considerations for shapefile output for more information about shapefile output.

Reduce data size

Any software that processes data works faster when the dataset is small. There are a couple of ways you can reduce the size of your geographic data:

Use Synchronous mode rather than Asynchronous mode

Synchronous means that client waits until the server has finished executing the task. Asynchronous means that the client is free to do other work while the server executes the task. Executing the same task in synchronous mode is about a tenth of a second faster than executing it in asynchronous mode.

Learn more about synchronous and asynchronous execution