Good morning, I have a question regarding optimizing performance of ArcGIS Enterprise and was hoping someone can provide insight.
I currently have 3 machines to deploy ArcGIS Enterprise 10.6.1. I plan on having Portal for ArcGIS as well as ArcGIS Server. From a performance perspective, what would be the most ideal?
1. ArcGIS Server running on all 3 machines, Portal on Machine A, and the two web adapters on Machine B.
2. ArcGIS Server running on Machine A and B, Portal and Web Adapters on C.
3. ArcGIS Server running on A, Portal on B, and Web Adapters on C.
Machines are virtualized, each with 4 cores allocated from a 2.4ghz Xeon E5-2680 V4 and 8GB of ram.
Any insight is greatly appreciated, thanks!
A critical aspect that's missing from this equation is the ArcGIS Data Store.
Which type of data stores will you be implementing? If you're going to enable the Spatio-temporal datastore, I'd argue that needs it's own machine.
Which ArcGIS Server roles will you be implementing? That will also factor into this decision.
Will your GIS be public, or internal facing only?
What kind of volume are you anticipating in terms of site visits?
Randall Williams thanks for your reply,
No plans to enable Spatio Temporal datastore, most likely just relational and tile cache.
- Roles will be managed using our Active Directory.
- Internal facing only
- We have a relatively small GIS team of about 12 users who can create maps. Most likely under 30 users that will view content.
Thanks again for your time.
Where' is your "Relational" (DB) machine in this stack? If that is a 4th machine that you didn't mention, then Option 2 will give you the best performance, which is similar to how I deployed: 10 Arc GIS Servers, 3 SQL/SDE Instances, 1 WA, albeit Portal is in a bit of a different location. Regarding the question about the data store, based on your use of the word "Relational", you don't need one, as the data store is a black box where you're hosted feature services go and there is nothing relational about them. Hosted feature services aren't for everyone, you'll do nicely with a relational database driving services hosted on your two Federated Servers. However, if you think you'll grow (as I knew I would), go with Option 3. Adding more GIS servers to the stack is cheap, easy, and fast; re configuring your Portal and WA to be on separate machines AFTER you deployed them to one will be a hours-days-long tech support case. Plus you get a dedicated host to deploy other web apps (e.g WA Builder) as well as dedicated hardware to overcome the hit your going to take for SSL. Option 1 is very unrealistic and will cause all kinds of https problems and would only work if you doubled the number of servers and turned into a high availability solution.
Back to Option 2, here's how I "sorta" do it: I reserve a pool of GIS Servers just for editors. You get a map and feature service when you publish, but no one connects to the map services when they're making maps, just the editors connect to the feature service when they're editing data. I need for the editors to have reliable confidence that stuff's going to work so they stay out of my office complaining about feature services not working. So in my isolation model, valuable CPU cores, memory, and a hard limit on service instances (Pooling) can meet Editor Demands. Think about the Sync services on the "Editor" GIS Server, whenever you do offline sync, the service gets a workout. If the editors can't edit, there's nothing for the mappers to map. So this is your first GIS server
For my mappers, I publish and sync just map (and tile) services to another pool of GIS servers (a variety of other platforms, AGOL, Mapbox, Carto, etc...) where I have to spend less time worrying about performance and balancing instances. There are a few rare instances where I have editors and mappers hitting the same REST endpoint (e.g sensitive data). This is your second GIS server. A variation of this is to put all of your "map stuff" on AGOL, and use the two GIS servers for Feature Services (Editors).
Thanks for the very informative reply Thomas!
I guess I should clarify that I also have a separate SDE environment. The plan is to federate the SDE databases to my server(s) and publish REST services that will serve directly from SDE.
This 3 server deployment will strictly be used for Enterprise deployment. Our current deployment (older server machines that will be decommissioned) is essentially option 2 with no portal: 2 Machines with ArcGIS Server and 1 Machine with the web adapter.
I'm curious just how resource intensive the web adapters and Portal are and if there is a benefit of running server on all 3 machines to serve up REST services layers. Web Adapter is supposed to perform load balancing to my knowledge.
I can't possibly imagine a scenario where running all 3 on the same machine would ever work anywhere outside of a test lab. Trust me on that one. with 12 editors and 30 mappers, you'll be looking at 100% CPU utilization 24/7, and will not be able to spawn very many service instances. The Web Adapter could basically run on an i386 with 48k of RAM, IMHO, but Portal is very hardware greedy. If you're going to get into load balancing, I suggest looking at a hardware solution.