ArcGIS Server 9.3 introduces 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 tile 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 put an unnecessary hit on performance when misused or overused. This topic contains 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 beautiful, complex maps very quickly because the server is just distributing tiled images of the map; it isn’t drawing the map on every request. However, when you use on-demand caching, the server does have to draw tiles dynamically when a user navigates to an uncached area. This dynamic draw actually takes longer than a regular request because the server creates a group of tiles at once. This group of tiles is 4096 x 4096 pixels in size (equivalent to 64 tiles of 512 x 512 pixels).

Why doesn’t the server just create one tile at a time? If it did, you would see many duplicate labels because there is no way for the labeling engine to determine what labels exist on adjacent tiles. Hence the server creates a group of tiles at once and you must prepare your map for drawing large areas at an acceptable speed. This section discusses 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 pre-cache. Never use on-demand caching to build your entire cache. You should always pre-create 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.

How do you determine which areas of your map will be most popular? This largely depends on the purpose and audience of your map. In a general base map, populated places, roads, coastlines, parks, and other points of interest have the potential to be visited more often than other areas. Microsoft Hotmap is an interesting case study that shows popularity of tiles in the Virtual Earth base map at multiple scales. Notice that at larger scales, the percentage of unused tiles increases.

Thematic maps might show very different trends of popular places. For example, maps used by a mining company might have 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 pre-cache, examine the usage patterns of your current maps, either online or on the desktop. You can learn a lot through informal observations of where your users tend to navigate and which features they query.

Your data availability and resolution is also important. If your 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, you’ll want to make sure areas with a high density of roads and rails are pre-cached. 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, you should create a feature class that isolates these areas. You’ll 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 post-processing on the output to ensure that the resulting feature class is suitable for a caching template. For example, the feature class whose boundaries you cache against should not contain numerous, small features. The Aggregate Polygons tool can eliminate small holes and polygons, and the Dissolve tool can create one multipart feature from numerous features.

The more you can isolate popular areas of your map, the more requests you can satisfy with pre-cached tiles instead of creating tiles on demand. For example, you may find that at a large scale level, you only need to cache a small fraction of your map area to accommodate 99% of user requests. You may decide to use the disk space that you save to strategically cache additional scale levels.

Testing and optimizing the map

Many organizations have complex map documents (MXDs) 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 your map, you may want to 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 your map, for example, urban and rural, flat and mountainous, and so on. Note the time it takes to create the test cache. Then 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 can choose to not make any adjustments.

If you want to improve performance of the on-demand tile creation or even the general cache creation speed, you can follow some of the tips presented in Map authoring considerations for ArcGIS Server. This topic explains ways to optimize your map document for performance on the Web. Look in the section “Performance tips for non-cached maps” for these tips. In general, you should remove unneeded layers and use the simplest symbology acceptable for the features you do choose to show.

One way to detect inefficient layers in your map service is to set the ArcGIS Server logging level to Info:Detailed. Make one draw request to the map service, such as zooming to a bookmark in ArcMap. Then examine the ExportMapImage request in the logs and note the draw time for 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 your different cached scales in random areas of the map. Remember to set the logging level back to Normal when you are finished, as Info:Detailed writes more log information than you normally need.

Once you’ve optimized your 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 opt to do one of the following things:

• Pre-cache 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 not many features will have to be drawn at once.
• Make a full cache. By pre-caching all of 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 script caching jobs to occur on nights and weekends to steadily build your cache until it is full. You can also choose to devote just one service instance to caching while other instances handle user requests.
• Use a dynamic service. If building a full cache is not feasible and performance is acceptable with a dynamic service, you might choose to skip caching entirely. Although this option does not give the best performance, the maps you show will always be up to date and you will not have to create or manage a cache.

Updating tiles

When you edit your source database, you need to update the cache before users can see the changes. If you follow the recommendation of pre-caching an area based on a feature class and filling in the rest of your cache on demand, you’ll need to be careful that the updates include all the necessary areas.

There are two strategies you can follow to update your cache when you’ve been creating 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 pre-cached 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. You should delete tiles based on the inverse of the feature class you pre-cached against. You can use ArcGIS editing tools to make a polygon representing the full extent of your map and cut a hole in it for the area that was pre-cached. The resulting “donut polygon” is the area where tiles should be deleted. See Common Polygon Editing Tasks for one explanation of how to cut a hole in a polygon using the Clip command.

  Alternatively, you can delete all tiles in the cache before you start the update, but this might add some overhead if your cache is large.

  If you’re worried that users will have to wait for a certain place to be cached on demand after every update, you should think about adding this place to the area that is pre-cached. When you’ve pre-cached wisely, on-demand caching should only occur infrequently in random patterns in the less-interesting areas of your map. If users are constantly returning to a place, it should be pre-cached.

• Target your 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, then export these changed areas to a feature class and update tiles based on the feature class boundary. Tom Brenneman’s tool Show Edits Since Reconcile can be helpful for this workflow. Alternatively you could use the Feature Compare tool to compare an edited copy of a feature class with an old copy and export the changed features.

  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.

Contributed by Sterling Quinn of the ArcGIS Server software development team

This information was recently added to the ArcGIS Server Web-based help as Strategies for on-demand caching