Timeout of layers -- max # of instance for dedicated pool??

[Laura]

I am new to the instance side of enterprise. I have moved my users over to new maps in Portal and there seems to be a lot of timeout of layers with them not loading and various random issues. What should I be setting my max instances to per machine? All of my Enterprise deployment is one 1 server (hoping to change that in the future). I was told use dedicated for those that are used a lot (which is most of my layers) but it hasn't seemed to help at all. 

[jcarlson]

It really depends on the kinds of workflows the layers will support. Have you looked at using shared instances, though? Unless you're working with an advanced dataset like the parcel fabric, etc., shared instances can really smooth things out. We've got dozens of layers being used all day, but since they use the shared instance pool, performance is pretty stable.

[Laura]

I was told dedicated is the way to go but now I'm not so sure. 

[jcarlson]

It might be, but it's going to be case-by-case. I would be skeptical of any advice that applies a blanket policy to all use cases, at least on this topic.

To give you more examples, our main public layers (parcels, boundaries, etc), are in the shared instance pool. Those layers are referenced by dozens of maps, apps, Pro projects, and Survey123 forms in use most business days. I have never had an issue with the service itself failing to respond.

Our parcel fabric, on the other hand, is completely internal, with perhaps one or two users editing it on a given day. It actually doesn't need more than a couple of dedicated instances, and we even set the minimum to 0 because there's no impact to our stakeholders if the layers take a few extra seconds to start up initially.

What you're running into is a large number of ArcSOC.exe instances running on your server machine, one per dedicated instance. It really won't take long to max out your server that way, and it will seem like your performance is suffering. You might even consider getting more server cores licensed.

Go ahead and move a bunch of your layers to the shared instance pool and just see how performance changes (or doesn't!). If you find it's not adequate to your needs, you can easily switch it back to dedicated instances.

[Scott_Tansley]

Hi Laura, this is a massive topic.  I'm a bit maxxed out, so I'll try and provide summary info.

A single machine deployment of ArcGIS Enterprise is possible, but it should IMHO be ring-fenced for Hosting Services only.  Map, Image, geoprocessing and any other services are a bit heavy to run on a machine that is already running portal, server, two datastores and two postgre SQL databases.

If you're using services beyond hosting, then put them on a federated server for these reasons:

https://enterprise.arcgis.com/en/get-started/latest/windows/additional-server-deployment.htm#ESRI_SE...

When you've got that second machine then the number of dedicated instances is typically governed by the number of vCPUs that you have.  If you have 4 CPUS then any given map service (for example) should have no more than 5 dedicated instances.

I typically see that most of my clients use about 80% of their services in the shared pool, with only extremely high-use services being of the dedicated type.

Sorry, there's a lot more in this subject, but those are some rules of thumb and best practices.

[Laura]

Really insightful feedback, thank you! Esri doesn't go into a lot of detail so I needed more input before changing it up too crazily. 

[Scott_Tansley]

Every case is different.  There are some very detailed documents aimed at uber-architect type people, but the way that Enterprise is used now, i.e. very fluidly, it's actually a dark art to get it perfect.