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; } } }

Guidelines for Maximum Number of Hosted Layers on a Hosted Server?

KevinBoes2

I work for an organization making use of ArcGIS Enterprise and ArcGIS Online. We have lately been expanding the amount of data available in our portal, and we are trying to ensure that our infrastructure will support the new services living in our servers.

Historically, our organization has focused on publishing datasets as referenced services which use either dedicated or shared instances. We have been told that for each ArcGIS Server we stand up, we have 200 ArcSOCs or instances maximum, and it is better to keep the number of ArcSOCs in use to 150 or lower to avoid performance issues.

While working through the ArcGIS Enterprise: Choosing Between a Hosted Service or a By-Reference Service course in the Esri Training catalog, I noticed language suggesting that hosted services published to the Hosted Server don't use the same ArcSOC mechanisms, and one could publish more hosted services to their Hosted Server without experiencing performance issues, as a result.

In the interest of understanding the architecture implications of shifting towards using hosted services more often, is there a maximum number of hosted services which can be published to a Hosted Server? If it is not a constant number, is there perhaps a relationship between the amount of memory available on the server and the number of hosted services which can be supported?

Encuentra más publicaciones etiquetadas con

Accepted answers

ArchitSrivastava

@GlenterpriseUK and @TrevorH_OPE both made really good points.

I would just like to add that even though hosted feature layers do not use the same dedicated ArcSOC instance model as traditional referenced map/feature services, I would still be cautious about thinking of hosted layers as “unlimited.”

For referenced services, the concern is often tied more directly to ArcSOC instance usage, especially when services are configured with dedicated instances. Hosted feature layers are different because they are managed through the hosting server and the relational ArcGIS Data Store, so the limitation is usually less about a fixed service count and more about overall system load.

From my understanding, the practical limit depends on a mix of factors, such as:

Number of hosted layers.
Number of records and geometry complexity.
Frequency of queries, edits, sync operations, and exports.
Attachment volume, especially from Survey123 or Field Maps workflows.
Number of hosted feature layer views.
Number of web maps, dashboards, Experience Builder apps, and other clients consuming the same layers
Relational Data Store size and growth rate.
Backup and restore time for WebGIS DR or Data Store backups.
Disk I/O, available memory, CPU usage, and network throughput.
Whether the layers are mostly inactive or being actively edited and queried.

So in practice, hundreds of small hosted layers with light usage may not cause much trouble, while a smaller number of large, heavily used hosted layers can become a problem much sooner. For example, layers with large attachments, frequent editor tracking updates, offline sync replicas, or dashboard-driven queries can put much more pressure on the relational Data Store than the layer count alone would suggest.

I also agree with @TrevorH_OPE point about keeping hosted content tidy. In Enterprise, hosted layers are often created by users for projects, surveys, testing, dashboards, or temporary workflows. Over time, that can quietly turn into a large amount of stored content, attachments, views, and dependencies. Ironically, a lot of “temporary” hosted content can become long-term operational content over time, especially if there is no regular review, ownership tracking, or cleanup process.

For planning, I think it helps to separate hosted content into categories such as:

Active operational layers
Authoritative production layers
Temporary project layers
Survey123 or Field Maps layers with attachments
Test or training layers
Archived or inactive layers

That can help identify what should remain hosted, what might need to be archived or cleaned up, and what may be better managed as referenced data from an enterprise geodatabase.

So I would not plan around a fixed hosted layer count. I would plan around monitoring actual usage and system behavior: Data Store growth, service traffic, query/edit load, attachment size, backup duration, restore requirements, disk I/O, memory usage, and performance trends over time.

Hope it helps!

All comments

GlenterpriseUK

Hi @KevinBoes2,

There is no fixed maximum number of hosted services on a Hosting Server. Unlike services published as referenced services, you are not constrained by ArcSOC instance counts. Instead, the real limits come down to available hardware resources (CPU, RAM, disk space, and disk I/O). Something worth considering which is as important as the hardware resources is how those services are actually being used. Having said this there isn't a hard cap of 200 Hosted Layers.

What you’ve heard about the 200 ArcSOC limit is accurate, but it only applies to referenced services that use the ArcSOC process model (only on Windows deployments). Hosted services behave differently under the hosting server and Data Store, and they don’t consume ArcSOC instances in the same way. This is why you can generally support a larger number of hosted services without hitting that same ceiling. More on the ArcSOC limit can be read here Unable to Publish New or Start Existing Services When a Large Number of ArcSOC.exe Process

To conclude, the number of hosted services you can support will scale with your infrastructure and usage patterns rather than a fixed number. A system with sufficient memory and good disk performance can handle many hosted services, but heavy usage, large datasets, or complex queries will surface resource limits much sooner. So when planning a shift toward hosted services, it’s best to focus on monitoring and scaling your infrastructure rather than targeting a specific service count.

Regards,

Glen

TrevorH_OPE

Lots of "it depends", unfortunately.

The good news is that hosted services are essentially "on demand" so there are no dedicated ArcSOCs like you said.

Most orgs will have hundreds of hosted services on Enterprise and generally it works fine as there is minimal overhead for inactive services.

Problem areas I have come across;

1. Too many small services - creating a service with 1 layer with <10 features is dumb. Dont do it. Combine them or dont do it.

2. Uploading large datasets and publishing as a hosted feature service. Again dont do it. I worked with an AEC and someone published a cadastre dataset with 12 million polygons. It took the entire Enterprise down.

3. Keep it tidy - many orgs use hosted services with Survey 123 and upload lots of attachments. This is fine but keep it tidy and archive them when the project is done. The relational datastore behind the hosted services will grow immensley. Ive worked with orgs where their relational datastore is 1-2Tb and 90% of that is attachments. This impacts performance, backup size/time and webgis dr. You can look at something like Qonda Vault to offload attachments before it becomes a problem.

4A. Attachments work differently in AGOL so less of a concern there.

5. The other consideration is that hosted service (on Enteprise anyway) are generally user created content. So their problem. However this has come back to bite me before during migrations eg to a green fields platform. Its easier to republish authoratative content than it is to migrate user content.

Regarding memory, the relational datastore is a Postgres RDBMS so more is better. Generally 16Gb or more. Memory seems to have a bigger impact than CPU.

ArchitSrivastava

@GlenterpriseUK and @TrevorH_OPE both made really good points.

From my understanding, the practical limit depends on a mix of factors, such as:

Number of hosted layers.
Number of records and geometry complexity.
Frequency of queries, edits, sync operations, and exports.
Attachment volume, especially from Survey123 or Field Maps workflows.
Number of hosted feature layer views.
Number of web maps, dashboards, Experience Builder apps, and other clients consuming the same layers
Relational Data Store size and growth rate.
Backup and restore time for WebGIS DR or Data Store backups.
Disk I/O, available memory, CPU usage, and network throughput.
Whether the layers are mostly inactive or being actively edited and queried.

For planning, I think it helps to separate hosted content into categories such as:

Active operational layers
Authoritative production layers
Temporary project layers
Survey123 or Field Maps layers with attachments
Test or training layers
Archived or inactive layers

That can help identify what should remain hosted, what might need to be archived or cleaned up, and what may be better managed as referenced data from an enterprise geodatabase.

Hope it helps!

KevinBoes2

@GlenterpriseUK, @TrevorH_OPE, and @ArchitSrivastava, thank you for this information! This will be useful for us to have as we evaluate our current data serving strategies and potential future ones.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

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