Optimize performance in ArcGIS

ArcGIS allows you to make a range of resources available to users: apps, maps, layers, services, and data. To deliver the best performance for users who are accessing a resource, it is important to understand there are different methods of optimization, depending on the resource type. The options that are available may depend on the backend data source, the type of geospatial service , or other factors. Understanding different types of optimization is an important part of ensuring a positive and effective user experience.

This section covers general strategies for evaluating user needs, network design, and caching options. See Optimize web maps and apps and Optimize data sources and storage for additional information about specific optimization strategies.

Evaluate user needs

Optimization means more than just minimizing the response time for HTTP requests. A service that sends rapid, low-latency but unhelpful responses is not necessarily optimized. Determine who will use the resource or service and why. Understand the questions the user will want answered by interacting with the resource. Use structured testing to ensure the resource performs well on the different client devices that users will access the resources from. Incorporate user feedback about the usefulness of the resource both during development and after the resource has been available for general use.

User needs will also help inform what kinds of performance optimizations are worth implementing. If a resource will only be used a few times a day by a small internal group, it is not as important to optimize to the point that it scales to thousands of requests per second. That same optimization, however, could be vital for a resource that is used by a global public audience.

Design networks for performance

The design of the network where ArcGIS components are deployed is a key contributor to performance (both good performance and poor performance). Enterprise systems are often global in nature, serving users across a wide array of network conditions and connectivity, and there are important differences between ArcGIS components and workflows in terms of their reliance on network connectivity. The breadth of network considerations for ArcGIS workflows is broader than this topic, but some initial recommendations and considerations include:

  • In general, network latency impacts user experience more than network bandwidth for day-to-day GIS operations. For activities like downloading data, copying files, or viewing large imagery datasets, bandwidth is also important.
  • Traffic from ArcGIS Pro directly to databases is latency-sensitive. Many small requests are made while viewing and editing data or working with and changing schema.
  • Traffic from ArcGIS Server to databases, file or object storage also requires low latency and generally high bandwidth. This allows the Server process to access the data, transform it to match user requests, and send back an optimized response to users.
  • Clients such as browsers accessing web applications and web services are less sensitive to network constraints than desktop clients, as tools like the ArcGIS Maps SDK for JavaScript optimize requests to reduce excessive traffic.
  • Many modern networks blur the distinction between on-premises and cloud resources through network peering and other technologies, which can result in very low latency between cloud resources and on premise resources or clients. In general, it is recommended for clients, server processes, storage and databases to all be hosted in the same “network zone”, for example, hosting them all in the cloud, or all on-premises. In some scenarios, however, it is acceptable for clients to be separated from servers, or servers from databases. How suitable this design may be for your system is dependent on your network design and structured testing of the relevant workflows to understand the implications.

Use request and response caching

Repeated requests for resources can require significant computational overhead in generating those resources. Providing a cached response can avoid that overhead, reducing both system resource usage and response times. Maximizing the use of caching can significantly improve the performance of ArcGIS resources.

There is no one-size-fits-all approach to using caching with the variety of web applications and services that can be used in ArcGIS, but instead a variety of patterns that should be used with consideration and planning. Common methods for caching include:

  • Map image layer caching, where a map is pre-rendered into standardized raster tiles that can be returned to a client with no server-side map generation.
  • Vector tile caching, where the features from a map are pre-rendered into tiles of compressed and optimized vector data, and an external style file defines the display of the map.
  • Imagery layer caching, where an image service is cached into standard tiles (nearly identical to map image layer cache) to improve rendering speed or control client access.
  • Feature tile caching, where feature layers are queried using standardized extents, allowing the server process to cache the response and return cacheable headers to clients.
  • Client-side caching, where responses include a header or property that indicates the client can use the resource multiple times before re-requesting it.
  • Content delivery networks, which are complex components dedicated to caching responses to multiple points of presence across a geographic area or around the world.

Raster and vector tile caching take input data that which might otherwise be accessed dynamically through a map, feature, or image service, and cache it into tiles. These tiles are predefined standardized images that show rendered data. Cached tiles allow clients to request multiple pre-rendered tiles at the same time for a given scale, so there is wait while the server accesses and draws any backend data. Both raster and vector tile caching are enabled by creating tile layers, while feature tile caching requires additional configuration of the properties of a service.

Each of these caching strategies have a wide variety of configurations, options, and choices that need to be made during the optimization of a service. Consult Esri documentation, resources, and conference proceedings for additional guidance in these areas.

Related resources:

Strategies for map image layer caching

Map image layer tiles are raster images that display a pre-rendered view of data, which is then drawn on the client as a set of multiple, stitched-together tiles for each display extent. Raster tiles can be created from map services, hosted feature services, or image services, with slightly different considerations for each.

Raster tile caching is an effective method to use when delivering relatively static data that should be viewed in one primary cartographic representation. Map cache creation can be intensive in both time and compute resources required, so it works best for data that are infrequently updated. While raster tiles can provide excellent performance and scalability, they do not provide the user with the ability to query for attributes, identify features, or change symbols, turn off labeling layers, and so on.

While raster tiles were used for many years to delivery cartographic basemaps, these services most often use vector basemaps today for a variety of performance, map quality, and flexibility reasons. Raster tiles are still used to serve many imagery basemaps or services based on satellite or ortho-photography, as these services aim to present a single, carefully balanced layer of imagery as a background for applications or tools.

To learn more about map image layer caching, see these resources:

Strategies for vector tile caching

Vector tile caching is similar in concept to raster tile caching, but the tiles are compressed binary files (based on protocol buffers) which store vector features as geometry and attributes, cut into individual tiles which are then re-assembled and rendered on the client according to a separate style definition.

Vector tile caching is appropriate where a raster tile might be limiting or unsuitable for other reasons. Vector tiles can be faster to generate and smaller in size than raster tiles, which has benefits for storage of the tile set as well as in the speed at which they are transferred to a client over a network connection.

Vector tiles also allow for dynamic rendering through the use of a vector tile style, which can be configured or updated entirely on the client, such as a browser or native application, and can dynamically show or hide different layers, filter based on attributes, and display multiple different cartographic versions of the same data, all using the same single vector tile layer.

Strategies for feature tile caching

Unlike vector tiles and raster tiles, feature tiles are not pre-generated by a planned process. Instead, they are generated by functionality-aware clients requesting standardized extents of data for standard zoom levels. Since these requests are identical between different clients, the features can be cached and reused or re-sent to different clients. This functionality is exclusively available for use by clients that are designed to use this feature, primarily through the ArcGIS Maps SDK for JavaScript, as well as through ArcGIS Pro and native applications built with the ArcGIS Maps SDKs.

The use of feature tiles relies on two key assumptions:

  • The service supports feature tiles. Feature tiles are only used when making requests to feature layers (based on a map service or feature service) that support this capability, which varies by release. ArcGIS Online-based hosted feature services have supported this functionality for several years. In ArcGIS Enterprise, the individual layers in a hosted feature service need to be configured using a REST API request to enable feature tile caching, and the cached feature tiles are stored in the object store.
  • The client making the request supports feature tiles. Usually, clients that support feature tiles automatically request them from services that support them. While ArcGIS Online provides several layers of caching for these feature tiles, ArcGIS Enterprise-based layers have additional considerations for making best use of this feature.

Hosted feature services in ArcGIS Online also include an option to enable optimized layer drawing, which can generate reduced-resolution data in the database that are used to display smaller (more zoomed-out) scales. This reduced-resolution data is automatically queried by the feature tile generation process when using those scales, which in turn improves response performance.

To learn more about feature tile caching, see these resources:

Strategies to optimize client-side caching

In ArcGIS Enterprise, you can configure both map and feature services to return a Cache-Control header that allows a user’s browser to take advantage of caching response content based on an Etag value. 

When clients send requests to ArcGIS Server to request a map export or query a feature service with this setting applied, the response from the server can then typically cached by the browser and reused for a certain period of time. However, depending on how your map or feature service and its associated data are used in applications, you may consider adjusting the length of time the browser will use a response in its cache. This can be achieved by adding a property named cacheControlMaxAge to the JavaScript Object Notation (JSON) definition of the service.

Content delivery network (CDN)

A Content delivery network (CDN) caches content on edge servers that are located in closer geographic proximity to the user. CDNs reduce response times for requests by eliminating the need for a database query and reducing latency from longer network travel.

Both publicly-shared hosted feature layers and the web application static assets hosted in ArcGIS Online automatically make use of a global CDN for caching of feature tiles and static app responses. Learn about controlling the CDN cache for hosted feature layers in ArcGIS Online. The ArcGIS Online CDN is also used to accelerate the response for public cached map image layers (raster tiles) and vector tile layers, as well as the various ArcGIS Online basemap services.

CDNs can also be used with web applications hosted in ArcGIS Enterprise but be careful to make a distinction between static assets that are suitable to caching in a CDN, such as HTML, CSS, and JavaScript files, and more dynamic REST API responses that should not be cached to avoid unexpected user behavior. Also take particular care in considering the use of a CDN as it relates to upgrades. The CDN cache should be forcefully invalidated when ArcGIS Enterprise is upgraded or an application changes to ensure users do not receive outdated information.

The blog post A Content Delivery Network (CDN) approach to ArcGIS Enterprise using AWS CloudFront provides one example of using a CDN with ArcGIS Enterprise.

Top