Shared Instances & ArcGIS Server

Making better use of the infrastructure you already have

Introduction

The reality in GIS, especially in the public sector, is that many of us wear a lot of hats. Maybe I’m a DevOps Engineer today. Tomorrow I could be a database administrator. Or tech support. Or a graphic designer. Or an actual developer, even!

So, I was at a social gathering the other day, making the usual small talk. Where do you live, what do you do.

The guy I was talking to works in the Tech Industry, and he almost seemed offended when I told him that I was a “developer”. Based on what I’d told him about my work, he informed me that I’m “actually a DevOps Engineer”. Okay? He made the same point at least two more times. Call me whatever you need to to preserve your taxonomy, I don’t care!

Here’s the thing: I hadn’t even told him what I’d done at work the week before. Or the week before that!

I like having lots of hats, keeps things interesting. But I put them on in a reactive way. As needed. I’m not wearing the fire helmet if there’s no fire.

When you operate this way over a long period of time, it’s very possible to start accruing technical debt.

(If you’re wondering, I am trying to set the record for most children’s books referenced in a single ILGISA talk.)

Our GIS setup can start to feel like this. When it rains, we run around bailing water out until the storm passes, but once it’s sunny? We’ve got other things to do, other hats that need wearing. As long as nothing’s breaking, right?

I know this is kind of a drawn out introduction, but it’s relevant! The topic of this talk is not something new, nor is it a fringe idea; you could have gone to the Esri Midwest UC in 2020 and seen Esri’s own Derek Law give a version of this. A version was presented at the virtual UC that year as well.

This is old news, a capability developed and promoted by Esri, and I am still shocked at how little I see it implemented. Esri’s got cool new things to talk about, and so they move on. But I think it’s still worth bringing up and talking about.

ArcSOCs

I really can’t do better than Esri’s own diagrams for this. Shamelessly lifting them.

If you’ve ever had to manage a Server installation, odds are you’ve seen ArcSOC.exe running on the machine. An ArcSOC instance is the thing that actually handles requests for your services.

The Old Days

Prior to 10.7, there was no such thing as a shared instance. Everything you published got its own dedicated service. The old Esri Design Strategy suggested three to five services per core on your server, so on single Server license, we’re talking maybe twenty services?

I think most of us have more layers than that, so the solution tended to be: publish a few MONSTER services that had three dozen layers in them. (ugh) But that sort of was the shared instances of its day.

Adding Layers / Services?

As time goes by, you may need to add new layers to your stuff. That means:

1. You republish a service with the new layer added (not zero-risk)
2. You publish a new service for that layer.

How do you avoid overloading your Server with too many socks?

Min Zero, Cold Start

This works, but honestly, it introduces slight delays when the service kicks on. Also, you’re just rolling the dice that your min-zero services won’t all be accessed at the same time. But what if they are? Are you ready for your server RAM to max out?

Let’s go to the Shared Instance Pool!

Okay, so let’s actually discuss shared instances, shall we? You can be as cool as this kid.

What is it?

A collection of ArcSOC instances not tied to a single service.

How Does It Work?

Note the “Participants” on the right. Requests can come in from literally any of those services, and there will always be a set number of instances ready to handle it. No cold start, and no possibility of a “perfect storm” swamping your server.

Query Caching

• Request info is cached per service
• Speeds up future requests for same services
• Takes up some memory

Tuning

• Number of instances in the pool
• Number of services cached

There’s no single best solution here, but I would urge you to play with these values to find the sweet spot for your organization. If you don’t have / need many dedicated instances, consider jumping to 6 or even 8 instances in the pool.

If you have a lot of shared instance layers, a 50-service cache may not be enough. Adjust as your system RAM allows.

When Should I Use It?

• Simple feature services
• Infrequently used
• You’re already using the “min zero” approach
• You’ve been looking for a way to break up those “monster” services

Honorable Mention: Hosted Feature Layers

Shared Instances Plus

• Stored in Portal’s built-in DataStore
• Service configuration / schema management via the web front-end
• Uses shared instance pool automatically
• Even more efficient use of memory

HFLs are super cool, and if you’ve got feature services that fit the bill for shared instances, they might actually make sense as hosted layers.

Resources

https://architecture.arcgis.com

Questions?

Be in Touch!

josh@jcarlson.page

https://jcarlson.page

@jcarlson@mapstodon.space