Performance tuning for cached map services

03-14-2017 03:06 AM
Occasional Contributor III

We've got three map services that have already been cached, with total cache sizes of between 10-20gb each.  There seems to be plenty of documentation and discussion around performance tuning to create the cache in the first place but I was wondering if there are any recommendations for service properties once the service has been cached.

If I monitor the arcsoc.exe process for one of the cached services in task manager whilst I'm interacting with the service then there appears to be 0% CPU use, presumably because it doesn't have to do any work to render the image and just goes straight to the tile cache. Would this still be the case if we had say 50 users all hitting the cache at the same time? In this case would it make a difference how many instances of the service there are or is the work of dishing up the tiles being done by a different process entirely i.e. javaw.exe, the web adaptor or IIS itself?

If it is still beneficial to increase the number of instances for a cached map service is this a case where low isolation could be used? I appreciate that there is potentially more risk of a crash bringing down all the instances within a process but gicen that the arcsoc shouldn't actually be doing much work is it a risk worth taking? I know ESRI recommend not using low isolation but why offer it as an option then? Is it really only of a benefit when RAM is in short supply on a machine?

If for example I wanted 9 instances in total of a cached service would it be better to have 9 arcsoc.exe processes in high isolation or 3 processes with 3 instances each in low isolation?

Any thoughts appreciated



Tags (3)
0 Kudos
1 Reply
Occasional Contributor III

Hopefully somebody can help answer your question.  I wonder about this too.  I've got several cached map services that I don't really know what to do with, and it doesn't help that statistics aren't available like they are for dynamic services.  My server doesn't have a lot of RAM to spare, either.

0 Kudos