Latest Contributions by JoshuaBixby

If you run into issues with vertical scaling, one area I have seen people run into problems is managing memory, both physical and virtual, at the OS level. ArcSOC processes have a surprisingly large virtual memory footprint relative to their physical memory use, and when scaling RAM up to accommodate more services, I have seen virtual memory sizing and use become a problem. Without knowing a lot more details about the application and OS configuration and spec's, I can't really offer any specifics.

Another aspect of why vertical scaling makes sense more than horizontal is licensing. I have always worked in large government organizations that deploy lots of what I refer to as "big brother" software, i.e., configuration management software, security software, monitoring software, etc.... Don't get me wrong, these types of applications are needed in today's environments whether they are small business or large government. As needed as they are, they consume resources and increase the amount of resources a machine needs compared to an idealized, bare-bones OS. For a previous organization I worked for, the rule of thumb was the first 2 vCPU were basically throw-away vCPU to support running all the big-brother software. This was more to do with poor management of the software by operations teams than the software itself. So, if capacity planning shows you would want 4 vCPU for a VM, we always spec'ed 6 to ensure the application would always have roughly 4 vCPU worth of capacity available. ArcGIS Server (not Portal, but Server itself) is licensed per core. Unlike some enterprise software like SQL Server where the cores can be set in the application, ArcGIS Server licenses all the cores on a machine. For situations like the one I describe where a certain number of vCPUs are set aside for other operations software on the machine, and yet those vCPU are still licensed for ArcGIS Server, horizontal scaling drives up licensing costs much quicker than vertical licensing because each new machine has those marginally used but still licensed vCPUs whereas adding more cores to an existing machine allows having the application use all those new cores. Regarding @Scott_Tansley comment about segmenting workflows into other ArcGIS Server sites, I agree, at least for medium to large customers. Each type of GIS service has its own unique patterns of use, both from the end-user consuming the service to the service consuming machine resources, and mixing them in large numbers often results in resource utilization and contention issues and capacity planning headaches.

I agree with @MichaelVolz . ArcGIS 10.8.1 is fully retired in 2 months, 08/01/2026. Besides the imminent retirement of that version, there are also practical issues you will run into. Although it may technically work, trying to publish GIS services from ArcGIS Pro to older versions like ArcGIS 10.8.1 will lead to problems. You won't be able to publish GP services, and there is risk of corrupt or unexpected results in map and image services.

The largest multi-machine ArcGIS Server site I have ever deployed and managed was 6 machines, and I have deployed dozens of smaller multi-machine sites. The 6-machine site was always the least stable of all multi-machine sites, and I didn't realize how much horizontal-scaling was a factor until we added more resources to the machines and dropped from 6 machines to 4 and then eventually 3. I have come to strongly discourage scaling horizontally above 3 machines, and I encourage people to look at vertically scaling instead by adding resources to machines. Although Esri doesn't state there is a maximum to how many machines can be in a AGS site, there is definitely a practical limit, and I have found it is lower than one would think. The main issue with horizontal scaling becomes the shared working directories, especially the shared configuration store. The IOPS for adding a new machine to a multi-machine site have always seemed to scale linearly, which on the surface sounds OK when thinking of how algorithms scale with data set size. However, when the IOPS are as high as ArcGIS Server's shared configuration store, horizontal scaling really starts to chew up IOPS. Vertically scaling generates no extra IOPS except for those additional services you are running now that you have more resources. Without knowing more specifics of your service types and uses, it is hard to offer any specific suggestions. Is there a reason you can't vertically scale?

I agree that ArcGIS Enterprise Functionality Matrix doesn't do a good job of explaining ArcGIS Enterprise Kubernetes functionality. There are statements about ArcGIS Enterprise Kubernetes, but they are more along the lines of "see this" or "see that" for information rather than clearly stating how Kubernetes functionality relates. That said, it seems like a simple question being asked, but it is hard to answer without knowing more of what you are really after. For example, since ArcGIS Enterprise on Kubernetes can federate with regular ArcGIS Server deployments, one needs to know whether someone's requirement is to only deploy in Kubernetes or whether a hybrid approach is allowed. If hybrid is allowed, than a lot more functionality and features are possible. The other complication is that the underlying architecture of deploying ArcGIS Enterprise on Windows or Linux vs Kubernetes is fundamentally different. Esri may make the REST APIs match, and the browser apps look and function the same, but under the hood they are very differently structured. Because of this, Esri will sometime use terms like "equivalence" instead of "parity," and they focus more on describing outcomes and workflows than features and functionality when talking about the two types of architecture. Overall, I agree with the sentiment that Esri does not do a great job helping customers understand the difference. Also, I really don't care for blogs as being "official" documentation, but the "Summary of Supported Functionality" in the What's New in ArcGIS Enterprise 12.0 on Kubernetes blog is about as authoritative as I have seen.

Thanks to @DanPatterson in the Performance matters - now more than ever thread for pointing out arcgis-geometry - Esri-build | Anaconda.org. It seems Esri is building a new "high-performance Python geographic geometry library for the ArcGIS platform, implemented in Rust." Since the public documentation of this Python library is non-existent, I downloaded the conda package and did code inspection of the Python and Rust components to learn a bit more about what is coming down the road. I wanted to share a few illustration I had created to help folks get a sense of it. One important note, Esri states it is "implemented in Rust," not that it is written in Rust. That is in important choice of words because the Rust part of the library is a very thin wrapper that sits between the underlying Esri ArcGIS Runtime Core and Python.

Browser-based, Web GIS apps built on JavaScript will not "see" fonts installed on servers or local computers. These kinds of apps stream vector fonts over the web, so simply installing a new font on a machine doesn't make it available to them. ArcGIS Pro is a desktop app that has direct permission to read standard font files installed on the local machine, so installing a font on a machine does make it available to ArcGIS Pro while not making it available to browser-based, web GIS apps. If you are interested in working with custom fonts for Esri's JavaScript-based apps, it would be good to read Font | References | ArcGIS Maps SDK for JavaScript. It discusses the format fonts need to be in and where and how the apps look for and get fonts.

Can you describe your data schema and some examples in text here? Can you also share the SQL that each query is generating? A video is better than a screenshot, but I personally won't usually take the time to watch a video, and I am guessing there are plenty others on the forum that do the same, or don't in this case.

Assuming the context manager change with cursors was partially, or hopefully, driven by improving lock handling; I am a supported of the change. Regarding resetting a cursor, although instantiating a new cursor may be the right decision, existing cursors can be re-used within a context manager. That is, one doesn't have to create a new cursor if they want to reset a cursor and re-use with a context manager.

You could publish the same service using a different back-end data source, e.g., file GDB instead of SQL Server, to see if the issue is isolated to a particular type of data source.

‎05-01-2026

When applying multiple patches, the more efficient and effective approach is to use msiexec | Microsoft Learn multiple patch option: /update Install patches option. If you're applying multiple updates, you must separate them using a semi-colon (;). Using this approach you can apply 2, 3, or 4 patches in nearly the same time as a single patch, and even applying 10-15 patches only takes a minute or two longer than a single patch. Plus, using this approach ensures patches are installed in the proper order because the MSI installer takes care of sorting out order using MsiPatchSequence embedded in the MSP files.

‎04-28-2026

It would be more helpful if you shared details. For example, what happened in one specific instance and what did you expect to happen? What is the structure of the data set and what was the selection criteria you used? When it comes to AI, trust but verify. Without knowing anything about your data, your workflow, and what you asked Copilot specifically; it is hard to give much weight to a warning like this.

‎04-27-2026

@SimonSchütte_ct , the Esri Support article linked to is less "deauthorizing" and more "disabling." Deauthorizing implies returning the license, which is what happens on the desktop side, and renaming the local keycodes file doesn't return anything to Esri. And cancelling a license file isn't exactly the same as deauthorizing licenses either. Cancelling a license file does return activations back to the pool, which is the same outcome as deauthorizing a license, but not all ArcGIS Server licenses are activated using a license file. For me I see the links as workarounds to Esri not having a proper deauthorization mechanism for ArcGIS Server licenses, which is why I voted for this idea, but as I already mentioned I won't hold my breath they will ever create a proper deauthorization mechanism for ArcGIS Server licenses.

‎04-24-2026

I will upvote this idea, but I am definitely not holding my breath. My last job was working for a large federal government agency with a sizeable Enterprise Agreement. This issue was raised to Esri multiple times over 10+ years (could even be 20), and Esri expressed no interest in supporting deauthorization of ArcGIS Server licenses.

‎04-21-2026

OK, I think I finally understand (or mostly) what is going on with arcpy.da.Walk and multithreading. As you know, I created some synthetic datasets to represent a range of GDB structure, and have been testing those datasets on local SSD, LAN SMB (~1.25 ms), and WAN SMB (~20 ms). arcpy.da.Walk is an os.walk-shaped generator — one __next__() per directory — and it holds some in-process lock during each __next__() call, releasing between yields. A probe driving two Walk generators from two threads (thread A, thread B) showed the two threads' iterations alternate perfectly in lockstep (B, A, B, A, ...) on a gdb with feature datasets, with ~80% wall-clock overlap. So threads do get scheduled and do share the work, but they share it by taking turns at the lock, not by running truly in parallel. That puts a ceiling on how much threading can help. Total lock-holding time is bounded below by total work, so two threads can't beat one by much. The practical consequence is that how much threading wins depends on your gdb's directory structure. A flat gdb is one directory with one big yield, so two threads can't interleave at all. This means the second thread just waits until the first is done. A gdb with many feature datasets has many yield points and the two threads can rotate through the lock productively, which is probably where some of your time savings is coming from in your tests. In my testing, ProcessPoolExecutor gave a more predictable ~1.6-1.9× speedup at WAN latency regardless of gdb shape, because separate processes have separate arcpy state and don't share the lock at all. The tradeoff is the ~3s cost of spinning up each worker (fresh arcpy import, license check), which is fine if each gdb walk takes more than a few seconds but eats the benefit on fast walks. If you're walking many gdbs over a WAN, the biggest time savings is probably one process per gdb rather than threading within one gdb — that axis scales cleanly and doesn't depend on what any individual gdb looks like.

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by JoshuaBixby

Re: What is the fastest way to add a new machine to an ArcGIS Server site

Re: What is the fastest way to add a new machine to an ArcGIS Server site

Re: Portal for ArcGIS 10.8.1 Site Creation Taking a Long Time

Re: What is the fastest way to add a new machine to an ArcGIS Server site

Re: ArcGIS Enterprise Kubernetes / GIS Functionality Comparison?

High-level View of arcgis-geometry Python Library

Re: Is there a way to add fonts to Portal?

Re: ArcGIS Pro- Definition Query- Performing Opposite Query Than Expected

Re: Python in ArcGIS Pro 3.7 FAQ

Re: ArcGIS Server 11.5 query problem

Re: Patch ArcGIS without service start mandatory

Re: Public service announcement: Difference between Pro 3.3 and 3.4 add to selection

Re: ArcGIS Enterprise unable to Return Licenses to my.esri.com

Re: ArcGIS Enterprise unable to Return Licenses to my.esri.com

Re: A Fun Threading Situation With da.Walk

Re: What is the fastest way to add a new machine t...

Re: ArcGIS Enterprise Kubernetes / GIS Functionali...

Re: What is the fastest way to add a new machine t...

Re: What is the fastest way to add a new machine t...

Re: Is there a way to add fonts to Portal?

Python Snippets

Esri Forestry Group (EFG)