We have approx. 10 x master data sets that have been published as individual map services. Each of these services represent different data themes, but all have their own unique location identifiers. These services are being consumed via Geocortex and from this platform, we extract/use data from another database.
There is a discussion going on regarding why we have not combined all ten services into one large map service, with an identifier code representing each of the ten data sets.
In the past, I've only dealt with many individual map services and not one large one.
Can anyone reflect on any advantages and/or disadvantages of having one map service with everything in it, rather than 10x smaller map services.
If the services are cached/tiled, with individual services you can toggle the visibility of the layers. If you have one large tiled service, you can't toggle the visibility of individual layers.
It's been a bit since I've discussed this topic, but it used to be the case that a map service won't render in the client until all layers have been downloaded - so if you have 'heavier' layers, I'd consider those as separate services. That way the user experience seems better because SOME services will render while the others are in the process of loading. If you have many 'light' services with simple symbology, you can consider consolidating.
What's the driver behind this conversation? Are there resource constraints?
Combining layers into less mapservices will require less memory as less AGS instances would need to be spun up. As Randall pointed out, though, there may be a point with heavier services where the load time becomes excessive, so you would want to break that layer out into another mapservice. This will take some trial and error on your part where you can make use of ESRI's out-of-the-box server statistics and the AGS machines Task Manager Processes tab to analyze the load vs performance (free tools). If you have the resources, you could pay for ESRI's more robust server analysis tools.