nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Should I publish a web service with 40 layers or publish each layer as an individual web service service?

JuneAcosta

I need to build a viewer app with a layer list of 40 + layers.

What is the best practice for publishing a web service for a web app that needs 40 or so layers? Should I publish one big map service and add each layer to the web map using the url and the corresponding index number? Or should each layer be published as an individual service?

Thanks in advance...

Find more posts tagged with

Accepted answers

All comments

Brian_Wilson

We use a mixture, for example we have one collection for example of roads, parks, and water features (polygon and line) that works well as a single service and then we add other layers on top.

There is no way to group layers in the web map viewer so this allows grouping several layers into "map image layer" that is still queryable. (Pop ups work)

We found publishing the maps from desktop with many layers to be cumbersome and ended up building them in the web map viewer. Things did not come through consistently and it was too hard to go back, make a small change, and re-publish versus just fixing things in the browser.

It's easy for us now to start a new app by grabbing an existing map, adding or removing the required layers, and then saving it in a new name. For example our public web map is the basis for maps that have added layers we don't share with the public.

Hope this makes sense, it's late in the day.. Cheers

TanuHoque

In general, it is better to publish one map service with 40+ layer in it, rather than publishing 40 services. Because 40 services will take 40x more resources on your server. Just follow the same practice that you do in desktop such as set appropriate visibility scale range, turn layer's visibility state to off by default etc.... so that layers/features won't get drawn unnecessarily.

.. and add each layer to the web map using the url and the corresponding index number?

I was curious why do you want to add those layers separately in your webmap? Is there something you want to do but can't do if you add your map service as a 'map image layer'?

LongDinh

Hi @JuneAcosta ,

The decision is up to you based on your web service's requirements. The main things to consider are:

Expected service usage versus expected layer usage, and
Available server infrastructure.
Maintenance frequency

Point 1 is to do with fine tuning data access for your user. For instance, if there is a very popular layer in your large service, you might want to separate it and assign additional instances (resources) to it so that its requests are isolated from your other less popular layers.

In point 2, you should consider whether your available infrastructure has capacity with having x amount of services. When you publish a service, it will consume RAM and CPU cores. On your server, the process is called an ArcSOC.exe. Too many ArcSOC.exe processes can cause performance issues. You can read more about ArcSOC and instance allocation here.

For point 3, consider whether changes to the schema of your data is required. This will generally require some service downtime and will therefore impact your users as you update your data source/s

If you web service is simply for viewing, generally a single large service will be sufficient.

berniejconnors

I would recommend grouping your layers into several themes and create a map service for each theme, e.g., transportation, hydrography, administrative boundaries, buildings, utilities, land cover, zoning, etc. This will make it much easier for your map services to be re-used in other applications

Bernie.

Todd_Metzler

Building on the points already made in prior replies, I'll add a few more that pertain to Enterprise versions that support shared instances.

My environment: Enterprise 10.8.1 full stack.

We also have a mixture of aggregated and single source services like @Brian_Wilson . Our aggregated services are grouped by theme as suggested by @berniejconnors . We use ISO category themes. Computing resource allocation is the driving factor from the performance standpoint as @LongDinh has pointed out. We have upwards of 300+ services and have been able to effectively keep the lights on within our computational resources by leveraging the shared instances capability in Enterprise Server to reduce the total amount of ArcSOC.exe processes. Now, to most effectively take advantage of shared instances, your service publishers should use ArcGIS Pro instead of ArcMap.

Reiterating. It's up to you. Consider your available computing resources 1st, your end use cases second and publish away!

Todd

David_Brooks

To build on all the good points above, i would add the following:

1) If performance is important and you're working in AGOL, the individual services would speed up the fetching of data to your web map, but would consume lots of internet bandwidth. And in Enterprise, you'd have the added challenge of consuming lots of server resources. You would also have a high initial administrative burden to get the data published, and then a low administrative burden later on when updating layers intermittently.

2) You can group feature layers in the new Map Viewer, but if publishing from Enterprise, you might get better performance and easier administration by publishing a map image service.

3) I would definitely (and do myself) gorup your layers thematically, and manage that way. You can also have customer layer lists to separate out and manage your layers in the web app. But the new grouping of feature layers pretty much negates that as useful functionality.

4) why do you want to consider adding layers from a combined service individually from their URLs and index numbers? Just add the item from your contents and they'll all drop in.

jcarlson

Some input from my own experience:

If you're publishing to a hosted feature service, then the number of services is less important, as they use the shared instance pool
If you anticipate wanting to access data across layers, such as a parks layer popup showing the number of bench points within it, grouping your layers in a single service is a major advantage, as you can access other layers using $datastore in an Arcade expression. Not that you can't do it in other ways, but it simplifies things.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.