Strategies for on-demand caching
Strategies for on-demand caching |
|
| Release 9.3.1 |
|
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.
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.
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.
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:
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.
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.