Select to view content in your preferred language

Map Service Layers count Limitations/Best Practices

2429
6
07-26-2023 12:55 AM
RedaAli
Regular Contributor

Hi, 

I'm  wondering if there is any limitations or best practices for the limited number (count) of layers can be added to one mapservice with or without FeatureAcces

Tags (1)
6 Replies
David_McRitchie
Esri Contributor

Hey Reda,

 

It depends and the number of features and size of the layers in the mapservice, but often I recommend to  keep the total number of layers at 10 or below. When layers are disabled there will still be requests sent out to these and so keeping the number reduced can really help ensure applications remain performant.

The following documentation is also worth checking as it provides performance troubleshooting tips and will show you how to check response times for services.

Hope that helps!

David

Esri UK -Technical Support Analyst
Scott_Tansley
MVP Regular Contributor

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/
berniejconnors
Frequent Contributor

BAU = "Business as usual" ?

0 Kudos
Scott_Tansley
MVP Regular Contributor

Thanks for asking/clarifying and yes.  I knew it was going to be an essay…

Scott Tansley
https://www.linkedin.com/in/scotttansley/
0 Kudos
berniejconnors
Frequent Contributor

Reda,

        I suggest you keep similar data sets in one map service.  For example, we have a map service for our hydrographic network (rivers, streams, lakes, wetlands, etc).  It has 15 layers but they are all related to the natural water drainage network - https://geonb.snb.ca/arcgis/rest/services/GeoNB_DNR_NBHN/MapServer.   The rest of our map services typically have 5 or fewer layers.

        Another consideration is the number of hits your map service may receive.  For example, our cadastral parcel map service is used in most of the web maps we publish and it gets many requests.  Our Parcel map service has ~600,000 records and just two layers - polygons and labels  - https://geonb.snb.ca/arcgis/rest/services/GeoNB_SNB_Parcels/MapServer 

        We have been publishing map services since 2009.  Our REST services directory is public - https://geonb.snb.ca/arcgis/rest/services.  Please browse through our services for more examples.  Feel free to reach out with questions.

Best regards,

Bernie.

 

Scott_Tansley
MVP Regular Contributor

Can’t argue any of that…. Nicely done Bernie 

Scott Tansley
https://www.linkedin.com/in/scotttansley/
0 Kudos