ArcGIS gives you the option to create map cache tiles on demand as they are visited by users. The first user to navigate to an uncached area must wait while the corresponding tiles are drawn by the server. The tiles are then added to the service's cache folder and remain on the server until updated or deleted by the server administrator. This means that subsequent visitors to the area will not have to wait for the tiles to be created.
When used wisely, on-demand caching can save you much time and disk space. Most maps show some area that is barren, unusable, or uninteresting to the map audience, especially at large scales (zoomed in). Caching on demand relieves you of the burden of creating and storing these unneeded tiles but leaves the possibility that a user could still view the area if needed.
Although on-demand caching is a useful feature, it can negatively impact performance when misused or overused. The following sections contain tips for using on-demand caching in the most effective way.
Achieving the best performance
One benefit of full map caching is that you can serve complex maps quickly because the ArcGIS Server site is distributing tiled images of the map; it isn't drawing the map on every request. However, when you use on-demand caching, the ArcGIS Server site has to draw tiles dynamically when a user navigates to an uncached area. This dynamic drawing takes longer than a regular request, because the ArcGIS Server site creates a group of tiles at once. This group of tiles is 2048x2048 pixels in dimension if the map service uses antialiasing and 4096x4096 pixels if it does not. As a result, you must prepare your map for drawing large areas at an acceptable speed.
Dive-in:
The ArcGIS Server site doesn't create a single tile at a time in this case because, if it did, you would see duplicate labels, due to the fact that there is no way for the labeling engine to determine what labels exist on adjacent tiles.
The next two sections discuss several ways to reduce the performance cost of on-demand caching.
Determining where you will cache on demand
The most important thing you will determine when configuring on-demand caching is which areas will be created on demand and which areas you will precache. Never use on-demand caching to build the entire cache. You should always precreate some tiles in the areas of the map you expect to have the most user traffic, thereby minimizing the chance that a user will consume server resources by requesting a tile on demand.
Determining which areas of a map will be most popular largely depends on the purpose and audience of the map. In a general basemap, populated places, roads, coastlines, parks, and other points of interest have the potential to be visited more often than other areas.
Thematic maps (as opposed to base maps) might show different trends of popular places. For example, maps used by a mining company might have their highest usage in areas where there is the greatest density of mines. This could occur in unpopulated or mountainous areas that would be uninteresting to the general population.
To determine which areas you should precache, examine the usage patterns of your current maps, either online or on the desktop. You can learn a lot through informal observations of where users tend to navigate and which features they query.
Your data availability and resolution is also important. If the data is poor or nonexistent in certain areas, you can skip caching those areas. Even if someone does request an on-demand tile, it won't take much time to draw if there's nothing to show.
Your data also might be closely tied to the purpose of the map. For example, if you're working with a department of transportation, ensure areas with a high density of roads and rails are precached. Spatial analysis tools such as Kernel Density can help you determine which general areas are thick with interesting features.
After determining where users will most often visit, create a feature class that isolates these areas. Reference this feature class when you run the Manage Map Server Cache Tiles tool, to ensure that tiles are only created within the feature class boundaries.
You might chain several tools together in a model or script to get this feature class of popular places. The model could contain various inputs of features anticipated to be popular, optionally buffer the features or determine their density, and finally perform postprocessing on the output to ensure that the resulting feature class is suitable for a caching template. For example, you can use the Simplify Polygon geoprocessing tool to remove excessive vertices that could slow down the caching tools.
The more you can isolate popular areas of the map, the more requests you can satisfy with precached tiles instead of creating tiles on demand. At a large scale, you may only need to cache a small fraction of the map to satisfy the vast majority of user requests. You may decide to use the time and disk space that you save to strategically cache additional scale levels.
Testing and optimizing the map
Many organizations have complex map documents that were originally prepared for desktop GIS purposes. These maps often need adjustments to meet the fast response times expected by web users.
Before you change a map, create a test cache of a small area to give you some baseline figures. Choose an area that contains a good mix of geography represented in the map such as urban and rural, flat and mountainous. Take note of the time it takes to create the test cache. Next, enable on-demand caching and zoom to an uncached area. Note how long it takes for the tiles to appear at various scales. If performance is acceptable at this point, you don't have to make any adjustments.
For advanced detection of inefficient layers in a map service, set the ArcGIS Server site's logging level to Verbose. Make one draw request to the map service, such as zooming to a bookmark in ArcGIS Pro. Then examine the ArcGIS Server logs in ArcGIS Server Manager and note the time it takes to draw each layer. You'll quickly be able to tell which layers are taking the most time. It's a good idea to repeat this exercise at different cached scales in random areas of the map. Remember to set the logging back to its previous level when you are finished, as verbose logging writes more log information than you normally need.
Once you've optimized the map, make another test cache and note how long it takes to create a tile on demand. If performance is still not acceptable, you can do one of the following:
- Precache a larger area. This way, the chance of encountering an on-demand tile is diminished. You can attempt to limit on-demand caching to only the most barren areas at the largest scales, thereby ensuring that few features will have to be drawn at once.
- Make a full cache. By precaching all the tiles, you won't have to create tiles on demand. This could be the best option if you have the time and space to create a full cache, and it won't be updated often. If server downtime while caching is a concern, you can program caching jobs to occur on nights and weekends to steadily build the service's cache until it is full. You can also devote just one service instance to caching while other instances handle user requests.
- Use a dynamically drawn service. If building a full cache is not feasible, and performance is acceptable with a dynamically drawn service, you might choose to skip caching entirely. Although this option does not give the best performance, the data in the map service will always be up to date.
Updating tiles
When you edit the cached map service's source data, you must update the cache before users can see the changes. If you follow the recommendation of precaching an area based on a feature class and filling in the rest of the cache on demand, you must be careful that the updates include all the necessary areas.
There are two strategies you can follow to update your cache when you're using created tiles on demand.
Delete all tiles that were created on demand before you perform an update
If you're creating tiles on demand, you probably precached a certain area based on a feature class. Normally, you'll also perform the update based on that feature class, and the on-demand tiles will become out of date if you do not delete them.
To delete the tiles, run Manage Map Server Cache Tiles using the Delete Tiles mode. Delete tiles based on the inverse of the feature class you precached against. You can use ArcGIS editing tools to make a polygon representing the full extent of the map and cut a hole in it for the area that was precached. The resulting donut polygon is the area where tiles should be deleted. See Cut a hole in a polygon feature for an explanation of how to cut a hole in a polygon using the Clip tool in ArcGIS Pro.
Alternatively, you can delete all tiles in the cache before you start the update, but this may adversely impact resources on the ArcGIS Server site if the cache is large.
If your users complain about having to wait for a certain place to be cached on demand after every update, add this place to the area that is precached. When you've precached wisely, on-demand caching should only occur infrequently in random patterns in the less interesting areas of the map. If users are constantly returning to a place on the map, it should be precached.
Target cache updates to cover only the areas where data was edited
One way to do this is to use geodatabase archiving or a custom tool to track all the changes since the last update, export these changed areas to a feature class, and update tiles based on the feature class boundary.
If you're sure that you're only updating areas where edits occurred, you don't have to delete all the tiles that were created on demand.