arcgis server - Lots of layers in one or multiple services? (and why)

I have a conundrum that I am getting mixed advice on how to go about. Therefore id like to put it to GIS-SE for some justified answers.

Scenario:

• 
  

  Client has a web mapping application. Does not want to split into multiple smaller applications. Although this goes against what the modern day approach is for maps on the web, (i.e. lots of focussed web-map apps over one main web-map) I strongly believe that for some users, trying to replicate a GIS application on the web is ok (sometimes).

  
  


• 
  
  

  Client has cached as much of his basemap layers into separate services.

  
  


• Client still requires an additional 600-700 layers in a dynamic map service...


• The service will be published with all of these layers turned off.


• It is not anticipated that users will turn on more than 10-40 layers at a time.

I imagine your initial reaction to this is similar to mine (600+?! WTF?!)

However - the requirement is set in stone and why not? Their prior ArcIMS application had similar functionality, so why can't this newer ArcGIS Server product do the same? The users potentially need to be able to cross compare and perform analysis on the entire range of layers, even if the layers belong to other departments.

Before you jump to conclusions, the client is a clued up ArcGIS Server admin.
They have administered the 600 layers by all of the best practice rules: e.g. scale ranges combined with definition queries; annotation over labelling; generalising complex layers at small scales; publish as MSDs; etc

Problem:

What is the better approach here?

1. 
   

   Publish all 600 layers into one dynamic map service

   
   


2. 
   

   Split the layers into logical groupings (hydrology, planning, ecology, utilities, etc)

   
   

If you go with #1, and you have a few complex layers turned on. If you want to turn on a simple points layer, then ArcGIS Server will still have to render the entire layers being displayed all over again.

If you go with #2, each time your making a request, potentially, the web application could have to make several GET requests for ExportMaps from the individual map services (is this bad, or does it create additional load to ArcGIS Server over #1?)

And then this leads to configuration & tuning to ensure everything is as quick as possible. We can scale the back end of ArcGIS Server to multiple hosts and have some good hardware to sit it on.

If you go with #1, you can throw the maximum # of instances that you AGS can handle.

If you go with #2, I assume you evaluate the performance of the map services (load testing and look at wait times) and address the min/max instances accordingly to ensure there is not one service that is a 'weak link'.

Im currently leaning towards the #2 approach, as my head is still telling me that having 600 layers in one service is madness, but if they are all turned off by default, there really is no issue.

Would love to hear your thoughts. Let me know if you need more info via the comments, but not looking for answers like 'use a desktop application' or 'educate them to do things differently'

---

From discussions in comments, I failed to mention another consideration. The application that the service will be consumed within, has the ability for layer level security (at the application level). Therefore the group of users (that is fairly large) are assigned to a particular role, and that role will have access to the full 600 layers. Other roles will be limited.

Answer

Used the Capacity Planning Tool to help compare one super heavy map service vs 4 lite map services, and the results indicate that the heavy map service is the way to go.

This may not be the right answer, and the capacity planning tool does not take into account every factor (e.g. user workflows) - let me know via comments what you think.

1 super heavy map service:
App Server CPU utilisation = 49.4%
Database Server CPU utilisation = 7.6%
Network load = 16 Mbps
Display Response Time = 0.88 secs

(Images can be seen in large by RC and open in new tab)

4 lite map services:

App Server CPU utilisation = 55.4%
Database Server CPU utilisation = 7.6%
Network load = 64 Mbps
Display Response Time = 0.32 secs each, so between 0.32 and 1.28 secs depending on web browser overheads

More logic to support the one map service approach:

1. 
   

   All layers are in the same map service, therefore;
   a. one request is sent to the server
   
   b. one SOC process draws the map
   c. one image is returned over the network

   
   


2. 
   

   The 40 layers are spread across 4 map services (10 layers each), therefore;
   a. 4 requests are sent to the server
   b. 4 SOC processes draw a map
   c. 4 images are returned over the network

   
   

1a and 1c will be faster and put less load on the network than 2a and 2c.

2b can use parallel processing to return a map quicker than 1b for a single user, but this will not be the case for many users. In fact, the overhead of the additional transactions being processed by the server in 2b (plus the additional network load of 2c) will see 1b scale much better as the number of users increases.