Det optimale produktionssystem burde have en cache pumpe som konstant producerer opdaterede map tiles for alle kort lag individuelt ... Optimeringen ville herefter ligge i at tune web serveren til at servicere store mængder af billedfiler ... Sårbarhed ville også blive mindre idet man ikke længere var afhængig af at database og al GIS server software var kørende ... i kortere perioder kunne man helt tage GIS delen ud af drift (til service) ...
/Sik
The optimal production system should have a map cache pump ... it would constantly run in the background updating map tiles for each individual map layer ... Optimizing the distribution channels would hereafter rely on tuning the web server to serve large quantities of image files ... This system would be less vulnerable to breakdown of the spatial database and the GIS server ... For short periods it would even be possible to take out the GIS production system (for maintenance) and still be serving maps ...
/Sik
Quote
How fast can you cache? We keep asking ourselves that and keep finding that the more we know the faster we cache.
If you’re involved in the job of caching maps for online map services, you are already familiar with the need to optimize the process as much as possible so that it takes less time and effort. One way you can do this is to optimize how your maps are displayed – another is to optimize the environment you are caching your map in or the circumstances under which you are caching. This blog post is dedicated to the latter.
Here is what we’ve learned in the past few months:
- Upgrade to ArcGIS 9.3.1. If you have not upgraded to 9.3.1, do it before caching because the file I/O for writing map cache tile images was vastly improved in the latest version. The result is anywhere from 25% to 2000% faster caching. Basically, the simpler the map, the more improvement you’ll see. That’s because simple maps draw faster and therefore file I/O is a larger proportion of caching time.
- Use more than one computer to cache. If you have the luxury of using several computers to do your caching, break up the caching job first by map level, and, if needed for the largest scales, geographically. Each portion of the job should be done such that tiles are being written to each of the several computers’ hard drives. When the caching is done, then copy the tiles from each machine into a master cache. One tip here is that we bought a software application called Secure Copy by ScriptLogic Corporation which made the job of copying possible for the largest scales where the potential exists to produce millions of map tiles.
- Set the number of processes to two. We’ve found that two is the optimum number of processes on each computer doing caching (we’ve been using 2 Duo CPUs E8500s each with 4Gb of RAM). One process just doesn’t take full advantage of available CPU and memory. Three processes pin the CPU, but actually produces fewer tiles per hour than two processes. Our theory is that file I/O is maxed out—we’ve been using 250GB and 1TB internal IDE hard drives.
- Turn off the option for indexing in your cache folder. In the Windows file manager, right-click on your cache folder and select Properties, then click Advanced (Windows XP), and uncheck the option “For fast searching, allow Indexing Service to index this folder”. This will make cache production 15-20% faster.
- Check your available memory. During our caching processes, we’ve usually got the Windows Task Manager open because we want to know how much memory is being used by the ArcSOC.exe processes that are being used to create the cache. This is especially important if you’ve got other services running on the server, because these services are taking up memory, too, and you want to make sure the caching process, which will be more demanding of memory usage, is not pushing out of your available physical RAM and into your pagefile.sys (which will result in catastrophically slower caching times!)
- Relocate the server’s pagefile.sys file. Unfortunately, stability of the caching process can be an issue, especially if you have other services running on your server. We’ve found one particularly good practice to minimize unexpected stoppage of our caching processes, which is to relocate the server’s pagefile.sys file onto a dedicated partition, preferably on a disk that is not primarily involved in caching. Minimally, we used to do this for printing large maps because it kept the pagefile.sys file from becoming fragmented, which limited the size of available memory blocks.
- Avoid having other services running while you are caching – this is really a summarization of the last few tips together!
Read more: http://blogs.esri.com/Support/blogs/mappingcenter/archive/2009/07/02/tips-for-caching-arcgis-server-map-services-faster.aspx
Ingen kommentarer:
Send en kommentar