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 a 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 formatAbout analyzing raster dataPerformance 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 thedataset. 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.
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.
The Select Tax Lots By Neighborhood (optimized) model in GP Service example: Selecting data preprocesses data using the Intersect tool. A new dataset specifically for the query performed by the model.
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:
Line and polygon features have vertices that define their shape. Each vertex is an XY coordinate. It may be that your features have more vertices than they need, unnecessarily increasing the size of your dataset.
If your data comes from an external source, it may contain duplicate vertices or vertices that are so close together that they do not contribute to the definition of the feature.
The number of vertices may not fit the scale of analysis. For example, your features may contain details that are appropriate at large scales, but your analysis or presentation is at a small scale.
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.
