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+?!)
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
What is the better approach here?
Publish all 600 layers into one dynamic map service
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.
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.