Maximum number of windows service instances on ArcGIS Enterprise servers

Question

Hi there,

a) Page 32 of this document mentions that 250 services (windows service instances) on ArcGIS Enterprise servers have an absolute upper limit, after which, in my experience, the may platform become unstable. Do you have experience by circumventing the Windows service instances constraint by editing the server registry? Would be interesting to hear how ArcGIS server performance worked after the change with both published and hosted services? And what kind of server capacity was used?

We are planning a future Portal for ArcGIS Enterprise 10.8.1 environment deployment for a large number of end users, and with this prospect we will have to exceed the limit of 250 Windows service instances due to the diverse workflows of business needs. I understand that the content of the services, and not just the number, will have a great impact on performance, it would be interesting to hear from others.

Here is an abstract on page 32:

'Dispelling old myths

Just as best practices are updated, there are certain beliefs about the software that are no longer true:

Myth: "Windows can only run approximately 250 service instances." (referring to SOC processes)

Truth: This is a Windows imposed limitation that can be lifted by changing a setting within the Windows registry. Remember! You must still have enough system resources (memory and CPU) to power all these services. Unless you have at least 50 GB RAM available for running services, you are unlikely to be impacted by this. See this technical article for more information and specific steps: support.esri.com/technical-article/000001218.'

We are also working to take advantage of the Shared Instances feature. This and this article will focus on leveraging Shared Instances.

b) Have I correctly understood that within the services, it is recommended to use a maximum of 20 map layers on ArcGIS Enterprise servers as well as ArcGIS Pro to keep them fast and stable in performance. Here is the documentation on the subject.

Thanks in advance for the tips and experiences 🙂

Todd_Metzler · Answer

JoshuaBixby wrote: "As an IT service provider, I have had many battles with lazy GIS staff who don't want to take the time to craft a high-performing map, but then somehow expect ArcGIS Enterprise to work miracles and turn it into a high-performance service."

Amen to that brother.

JoshuaBixby · Answer

You are asking several questions here.  Although the questions are related to tuning your site, and that is good background information to included, I tend to find threads focused on single questions get a bit more engagement from the community.

You don't mention what version you are working with, that is a critical piece of information to include.  The Esri Technical Support article you reference was last updated in 2018 and it was original written for 10.2.x.  Esri has made a fair number of structural changes within ArcGIS Server starting with 10.6.x, which came out in 2018.  Coincidence?  I don't think entirely.  I am not saying the Esri Support KB has incorrect information, it just has dated information that may not entirely apply to recent versions of the product in the quite the same way it did to older versions.

Optimizing an ArcGIS Enterprise deployment is very situational.  There are some common themes among the various documentation, but there is no silver bullet nor recipe one can follow step-by-step.  Understanding what documentation applies to a specific deployment comes from experience with managing ArcGIS Enterprise deployments and detailed knowledge of both a deployment and the organizational practices with using the deployment.  As Don Knuth famously said, "premature optimization is the root of all evil."

I would focus more on optimizing the use of the system rather than the architecture/deployment of the system.  Shared Instances are a powerful new feature, although not a perfect one.  They are definitely worth considering early.

In terms of services themselves, garbage maps make for garbage services.  When a map is small in terms of content or geographic extent, a lot of bad practices can be overcome simply by how powerful modern computer systems are, but there is a point where bad practices can not only impact the performance of an individual service but the system as a whole.  As an IT service provider, I have had many battles with lazy GIS staff who don't want to take the time to craft a high-performing map, but then somehow expect ArcGIS Enterprise to work miracles and turn it into a high-performance service.

Todd_Metzler · Answer

Hello,

My environment:  ArcGIS Enterprise 10.8.1 hosted on 2 physical Windows servers.  Server 1 [Portal, Server (federated, hosting); Server 2 (Server, Data Store (relational)]

I have 300+ services.  I did "step up" the heap size in registry once when we hit about 200 services.  That worked fine.  Concurrent with this change was migration of "simple" and/or low use services to shared instance.  The shared instance use somewhat reduces the need to modify heap size in registry because the total number of SOC.exe processes is reduced.  TIP:  Before trying any of these "tuning" techniques, evaluate your computing environment and ensure you are provisioned for current and anticipated system loading.  Each of my servers has 192GB of RAM and 2x 24 core processors.  These resources allow setting the shared instance parameters pretty high thus reducing the total number of dedicated instance service I have.

As far as your future plans with Portal:  Suggest view ArcGIS Enterprise as Portal/Server/Data Store not as individual pieces.  By implementing Portal and Data Store, we have overcome many performance limitations and/or resource "tuning" requirements inherent with Server only implementation.  Hosted feature services really "live" in Portal/Data Store.  All Server is doing is creating the service end point.  Perhaps an over simplification.  Hope it helps.

Read between the lines:  If you consider the interaction between ArcGIS Web GIS components and ArcGIS Enterprise, the writing on the wall tells me that it the not too distant future, ArcGIS Enterprise will be Portal and Data Store.  No more Server.

Lastly, if you don't want to bother with the Windows OS "tuning" and you can choose your OS (unfortunately I cannot), host ArcGIS Enterprise in Linux instead of Windows.  You'll require less computing resources for the same performance level and, in my experience, it just works without an overabundance of administrative care and feeding.  Yes setup is somewhat more involved but again, in my experience, worth the initial investment.