Strategies for on-demand caching

Release 9.3.1 E-mail This Topic Printable Version Give Us Feedback

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 popular tiles in an online 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:

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: