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

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.