Skip to main content

Enable response caching

Response caching is a backend server caching mechanism that can increase performance and scalability of feature layers. Clients that support response caching can make requests for standardized extents of data for standard zoom levels. Because these standardized requests are identical between different clients that request the same data, the features can be cached and reused by multiple clients.

Response caching enables clients to receive a response faster without requiring the overhead of a database query. That makes response caching especially useful for layers that need to scale to a very high number of similar requests. Response caching is best for data that changes infrequently.

Response caching for a layer can be configured by any of the following users:

  • The layer items's owner

  • A member of a shared update group the layer item is shared to

  • A member with the set of administrative privileges to manage content owned by members

Prerequisites to using response caching

Layers in ArcGIS Enterprise do not use response caching by default, and response caching cannot be used in every situation. To use the workflow in this topic to enable response caching for a layer, the following prerequisites must be met:

  • The layer item must be one of the following types that support response caching:

    • Feature layer

    • Hosted feature layer

    • Map image layer

    • Hosted feature layer view

  • The layer cannot reference versioned data.

  • The layer must allow response caching.

  • The layer must use feature data. Raster data cannot be used for response caching.

  • If the layer references registered data, the dataset must track the last edit time. If necessary, run the Enable Last Edit Time tool on the layer's dataset.

  • The hosting server must be configured with the object store.

  • Requests on the layer must be made by a client that supports response caching. Primarily, these clients will be ArcGIS Pro, web apps created using the ArcGIS Maps SDK for JavaScript such as Map Viewer, and native applications built with the ArcGIS Maps SDKs.

Configure response caching for a layer

Complete the following steps to allow response caching:

  1. Sign in to your organization as a member with the privilege to update the layer item.

  2. Open the item page for the layer item you want to update, then click the Settings tab.

  3. Under Response caching, click Manage layers

  4. Use the toggle to allow or disallow response caching for each layer, as appropriate for your needs.

    Layers that do not meet the requirements will have the toggle disabled and show a warning explaining why the layer cannot use response caching.

  5. Click OK.

  6. On the Settings tab, click Save to restart the service and apply the response caching settings.

Note:

Layers in a service published to a federated server site other than the hosting server must use the REST API to enable response caching.

Cache invalidation

Once a response is cached, it is only used for as long as it is valid. By default, a cached response expires after 1 day. An administrator can use the REST API to specify a different expiration duration. For information about configuring expiration duration for hosted feature layers and hosted feature layer views, see Response caching for hosted feature service layers in ArcGIS Enterprise. For information about configuring expiration duration for feature and map service layers that reference registered data, see Edit - Service.

If the object store uses a cloud service to store data, expired cached responses are automatically deleted. If the object store was configured using ArcGIS Data Store, periodically run the maintaindatastore utility on the object store to remove expired cached responses.

A cached response is also invalidated whenever edits are made to the layer's data to prevent clients from receiving a response with outdated data. A cached response invalidated by edits is replaced with a new cached response the next time the query is executed.

Note:

For layers that reference registered data, correct cache invalidation relies on the geodatabase setting lastEditTime. Edit operations made outside ArcGIS software, such as via SQL statements executed directly against the database, do not update lastEditTime. These edit operations may result in cache invalidation not working as expected.