I have recently been involved in creating a web mapping application that displays environmental monitoring locations over a very large area (approximately 7 million hectares). Of course one of the primary objectives in developing any application is optimization and performance and, with web maps, that usually means tile caching. So the development team came together (two of us in this case) and quickly decided what our zoom scale requirements were. We then tried to implement this which is where it all fell apart.
Because we were using the Bing Map Service as our base layer we were committed to using the zoom scales dictated within that service. Originally we decided that the minimum scale could be set to 1:9,244,648, which is one of the Bing mid-range zoom scales, however, we felt that the maps should be tiled the the largest scale possible; 1:1,128 in this case. Here in lies the problem. If you do a quick calculation to determine how many tiles are created using this range it is approximately 89 million, YES I said 89 million. Of which 98% come from the scales above 1:9,027. When we tried to tile with those scales the process would run for a number of days without finishing.
So how did we overcome this you might ask. By taking a more realistic view of our requirements and removing the unneeded scales from the tile cache. Once we removed the 3 scale values above 1:9,027 the process took less than an hour. We also made sure to have Tile On Demand checked for each service so that the tiles could be created on an as needed basis, prior to running the tile caching.
Lesson Learned: Before creating your Map Service infrastructure develop a tile caching strategy which should identify the largest scale you NEED, the number of tile cache layers and which layers MUST be cached. DO NOT include scales that you don't need and cache only the Map Layers that will be accessed FREQUENTLY.