Ask A Cartographer

How to cache map services with several computers

April 20 2010 | 5 comments
Categories: Web Maps, Publishing

I have a mapservice on large area (a national map) and I want cache it on 12 scale levels. I try to use ArcCatalog to do this, but it cannot complete the job. The reference on "http://blogs.esri.com/Support/blogs/mappingcenter/archive/2009/07/02/tips-for-caching-arcgis-server-map-services-faster.aspx" has the item "Use more than one computer to cache". How do I do this?  Thanks.

Mapping Center Answer:

The basic idea is to replicate the caching environment on a second computer and subdivide the caching job by either cache scale or geographically. That also means having ArcGIS Server running on each additional computer where you have defined an identical map service to be the basis for caching. 

When we do this, we expect to copy the cache files into a master service's cache to test and verify the complete product. We also run one last caching process on this master service after all the other files have been copied with the intent of caching any empty tiles to ensure all the tiles are present.

Managing disk resources is important--you do not want to have the other computers caching into the same cache location--that will make that location become file I/O-bound, meaning that all processes will be slowed down while waiting to write to that disk.  The same goes for the data being used in the MXDs that are the basis of the cached services.  Ideally, all the data is replicated for each computer that is caching.

We also prefer to have the data for the map on a different physical drive than the arcgisserver folder from where the cache is being stored.

In all cases, we use a rounded down 5/4 instances for caching per CPU on each computer.  So, a 2 CPU computer would have 2 instance, and an 8 CPU computer could have 9 or 10. Any more than this and we become CPU-bound.  For instance, 3 instances per CPU actually takes longer to complete caching a map than 2.  We have also found that for that last caching run on the master service using 1 instance, regardless of the number of CPUs is the most stable way to guarantee that a complete cache is produced.

To copy the cached files between computers we use SecureCopy or RichCopy.  We have both software applications in-house and I cannot advocate one over the other--both are sufficient for the task; and there are likely others. The important issue is that the Windows Operating system is not capable of moving millions of files around at once.

That said, all of this applies to ArcGIS 9.3.1. or exploded cache (versus managed cache) in ArcGIS 10.   We have not tried this yet with a managed cache in ArcGIS 10.

Last, this is not a precise science and took an accumulated set of experiences for us to learn.  Expect to have some trials (plural) and errors (plural).  Ideally, plan on it taking four to five times longer to actually get done than it will take to complete the caching.  We also check our caches within the arcgiscache folder initially to verify that we are getting what we expect from each computer caching--this allows us to find errors immediately and correct them, rather than wait until the caching job is done to find issues.

 

 

Re:How to cache map services with several computer posted by john shramek on Apr 22 2010 11:50AM
I'm surprised to hear it recommended to divy up the caching job and use separate computers, when more than one is available, rather than turn the extra computers into SOCs and use them all together. Is this really better, or did I read that wrong?

Also, the formula I got from esri, instead of 2 threads per CPU, is (5*CPU)/4, so for an 8-cpu server, 10 instead of 16. It's definitely worked better for me (9.3.1).
So noted posted by Charlie Frye on Apr 22 2010 2:43PM
On the subject of SOC and SOM computers--the way those work is that a SOC computer has the entire map (data, Mxd, and so on) replicated. But the cache is all on the SOM server--which gets back to the problem of being File I/O--bound. If you've got a RAID disk system on the SOM server, that would help, but it's still not a fully scale-able approach.

On thing I didn't mention when saying that the work could be divided by map scale is that I would also remove the extra layers from the MXD so that only those layers for the scale or scales being cached were present. that would make for a non-identical map service. This has the additional benefit of making the memory footprint of the map being cached smaller.

On the 5/4s item--I had forgotten we had official guidance, and have fixed that.
Re: posted by john shramek on Apr 23 2010 12:18PM
I can also tell you, there's an upper limit to the 5n/4 formula. I've gotten access to a monster 32-cpu (64Gb RAM) server, and setting the # of instances to 40 definitely did not work so well. I haven't had time to test for the optimal setting, but 12 seems to work fine.
Memory or CPU posted by Charlie Frye on Apr 23 2010 12:53PM
Is that based on Memory or CPU use?

If it's memory, then know that one setting we don't use for memory management is to have Windows manage the memory. When that is on, it often looks like all the memory is allocated when viewed in the Task Manager.
Re: Memory or CPU posted by john shramek on Apr 27 2010 3:58PM
that's based on it taking significantly longer to finish a cache. I don't think we had it set to let Windows manage the memory, but I'll double-check.

If you would like to post a comment, please login.

Contact Us | Legal | Privacy |