Map caching on demand

ArcGIS Server 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 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 2048 x 2048 pixels in dimension if antialiasing is being used and 4096 x 4096 if it is not.

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 precache. Never use on-demand caching to build your 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.

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 basemap, 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 basemap 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 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 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 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, 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 postprocessing 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 precached 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 percent 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 should use the Map Service Publishing Toolbar in ArcMap to identify and fix performance bottlenecks in your map. Use the toolbar to save a map service definition (MSD) file, which you should then use as the source document when you publish your map service. For many map services, using an MSD instead of an MXD as the source document results in an enormous performance gain.

For more advanced detection of inefficient layers in your map service, 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:

• 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 not many 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 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, your data will always be up-to-date.

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 precaching 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 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. You should 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 your 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 Cutting holes in existing polygons for an 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 precached. When you've precached 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 precached.

• 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.

  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.