Select to view content in your preferred language

Service configuration questions - instances, isolation, & SOC.exes

11250
12
10-01-2010 09:03 AM
TomCohen
Occasional Contributor
Hi,

There are many discussions in the forums about configuring min / max service instances for ArcGIS Server map services (set in the pooling tab in ArcCatalog / Manager) and I have spent a lot of time reading these threads and various pieces of ESRI documentation, but I still have a number of outstanding quetions that no one seems to answer.  If anybody can provide some input on these I would be extremely grateful!

1) The max number of instances (SOC.exes) is variously recommended as 3 - 4 per cpu core or 1 - 2 per cpu core (depending on which ESRI document you read...).  Assuming 3 - 4 per cpu core, is this per map service, or across all services?  This may seem like a dumb question but I just want to be sure.

2) How is max instances (see above) affected by high / low isolation?  If I have high isolation (1 thread per SOC.exe process), then 4 max instances must translate to 4 SOC.exes running (plus the system SOC process).  If I have low isolation with 4 threads per process set in the processes tab, and I set max instances to 4 in the pooling tab, will I end up with 1 SOC.exe (+1 system)?  If yes, does this mean that I can have 16 max instances (4 SOC.exe * 4 threads per process) on a single core machine?  This is the most important issue for me.

3) Are there any guidelines on the maximum safe number of threads per process in low isolation?

4) All documentation that I have seen on low isolation says something like "low isolation is less stable as if the container process fails the service instances that share the container also fail".  However the documentation never says what the impact of this is - will the SOM start a new SOC and complete any outstanding operations, or will the user receive an error?  Also, how likely is the container process to fail?  Could this happen from something like an SDE connection being closed by a firewall and a service instance crashing?

Thanks for anyone who can contribute on this
Tom
Tags (2)
12 Replies
JamalNUMAN
Legendary Contributor

This issue here is that there is no math equation based on which one can decide the min\max number of instances (ArcSOC.exe) needed for each published service.

 

In a test environment, we have been trying to understand service performance when executing actions such as panning, zooming, quiring, etc. We found out that, for example, zooming a service that contains a layer of 300,000 polygons is really a heavy action and would consume around 12% of the CPU (machine specs: 3GHz CPU, 4 Cores, 64 GB RAM, 2133 MHz). This means that if 10 users are zooming at the same time, then the CPU will get full just from zooming action on a service!

 

Zooming actions consumes on a service 12% of the CPU

Each ArcSoc.exe occupies around 80 MB on the RAM

 

Then imagine that we have 100 or 1000 users are zooming at the same time. Does this lead to the fact that no any server what the specs are will be sufficient to take care of services?

 

This could explains why our web mapping application fails at peak hours!

http://geomolg.ps/

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
DavidHoy
Esri Contributor

Jamal,

I know this is an old thread, but in case nobody else has followed this up.

May I suggest the reason your service is failing when you have more than a few users is that (it sounds to me that) you are asking the service to do something unreasonable - e.g. draw tens or hundreds of thousand of individual polygons at a scale where they will just draw on top of each other in the same pixel of the map image. The database query is returning all those records, and the SOC.EXE is then rendering each one  - no wonder it takes many seconds to draw a blob on the screen. If more than a few users are trying to use your web application simultaneously, their requests will queue up waiting to be serviced - and most users are impatient and will try to refresh the screen - which them sends off another request for the queue!

Please correct me if this is not actually the case and that you do have reasonable scale suppression defined in your map definitions.

JamalNUMAN
Legendary Contributor

What is causing ambiguity here is that there is no formula that associate between the demand and the resources.

How to determine the optimal number of ArcSoc that best fits the requests on a particular map service? or the only way to do this is “trial and error”?

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine