There are clear differences between map services and feature services.
If you create a map service then you can use it one of two ways. You can add:
https://my.gisserver.com/arcgis/rest/services/helloworld/MapServer
to the web map and things are really quite simple. The 'request' from your web map will use the exportmap function on the REST API and you will get an image back, like a PNG. It's a simple 'single' request and a simple 'single' response for each pan/zoom or other interaction. Boom.
However, if you have a map service with 100 layers in it, then the server has a lot of work to do to generate that image. Sometimes a 100 layers is necessary but should be avoided. My rule of thumb is if I get to 60 then I start to question if I can break it down. My sweet spot is 10-40 layers per service, but knowing there are always exceptions. It's not uncommon to see people create 100 services with 1 layer in each, and particularly if you're using Dedicated Instances, then this becomes inefficient. So, it's a balancing act, we don't want more than 100 dedicated services on a server, we want to maximise the use of shared instances, but still trying to stay within the sweet spot of 10-40 layers.
The emerging paradigm, and the second way of using map services, is actually not to request images at all. The common BAU situation is that people are not using:
https://my.gisserver.com/arcgis/rest/services/helloworld/MapServer
in their web maps, but instead adding layers one by one:
This is 'broadly' the same as using;
though feature servers do have extended capabilities, and beyond editing. I always ask clients to ask if they really need all of those capabilities, because if not they can query off of the mapserver instead.
In this model you are querying 'data' and getting 'raw data' back, traditionally in the form of JSON, but now in the form of PBF (much faster) in more recent releases. However, instead of 1 request (per service) for each pan/zoom, you will create MANY requests. The first request for each layer will be the 'query', this will determine how many features will be returned, and their OIDS, and then from there it will paginate through that list, creating 1 several requests. It will then do that for each additional layer. In this model the server has less work to do in creating an image, but has to handle many more requests. A point of note here, is that I recommend clients to consider using the Hosting Server if they know they're going to use this drawing method. It's lighter and scales much better, you can have thousands of individual services, instead of just 100 dedicated instance services or several hundred shared instance services.
Because of this iterative approach to getting data, the number of layers may seem less important, but I'd still try and stick to the 10-40 concept, challenge anything at >60 and now more than 100 unless you absolutely have no choice...
The user experience is often faster/slicker when using the image production from a MapServer. But it depends how much data will be returned and sometimes maps may only have a few points, in which case it doesn't matter. Images are great for avoiding the dreaded orange triangle, where theres too much data being returned from queries.
I recommend my clients to explore the options and get a feel for each method. I'm old school, I've been using Server since 9.2 and I still like the image response, but I know the kool kids want the data so they can do much more funky stuff in the web map. I get that, but it can 'sometimes' mean a slower map rendering.
In summary, it depends on how you're going to use the data as to the approach.
It's a tricky subject and it largely comes down to use cases and experience. There isn't a right wrong answer as such.
Scott Tansley
https://www.linkedin.com/in/scotttansley/
