Running ARCGIS Pro on Amazon Appstream

Question

HI All,

My client is currently running ARCGIS PRO  on Amazon Workspaces but doesn't feel performance is quite where it should be. For this reason, they are considering changing the platform from Workspaces to AWS Appstream so that it might take advantages of better performing GPUs.

I've done some initial research on this and while Amazon seems to support it without any qualification, it seems that getting informal information on it is scarce. There are a few posts here related to performance and some other areas but not as much as one would hope.

Most of the performance or usability issues seem to come in the form of the way ARCGIS does caching and some of the limits around the size of AppStream profiles. While this is useful I was kind of hopin for a bit more real world experience cases if you guys have any...both the good and the bad.

Thanks !

Bill

Dan_Joyce_OE · Answer

UPDATE: We're still having issues with Pro 3.2 running on AppStream.  I note that the latest ESRI doco for Pro 3.4 only references AWS Workspaces with links to the G4 & G5 instances.

Dan_Joyce_OE · Answer

Hi, I'm and end user and don't really have a solution for you, but my experience has been mixed with AppStream.

We are running ArcGIS Pro 3.2.0 in stream.standard.2xlarge AppStream instance.  We have been using this  setup for a couple of months for 2D workflows only.  We don't do much with 3D data, but wouldn't even attempt any processing or display in AppStream!

So far we have found the performance to be highly variable...some days it's okay and usable, other days there is a lot of lag when clicking on menu items or just waiting for some action to happen.

We have run some simple benchmarking tools to try and isolate when/where the bottlenecks are happening, but haven't found anything definitive.  These tests have been along the lines of:

* copy a feature class from an SDE enterprise DB to a local FGDB
* run a search cursor for records in SDE enterprise DB and local FGDB
* perform an intersect geoprocessing task

I recently found the deployment guide and it recommends using Compute/Memory optimised instances instead.  I've requested our IT department to spin one up so that I can run some comparison tests.

We only have a small team (< 5), so unlikely that the AppStream fleet resources are being exhausted, but we don't have any visibility of what is happening behind the scenes so don't know if we are under provisioned.

At times when the performance becomes so poor that you're waiting 30 seconds for a definition query to apply to a feature layer, the only option is to save, quit, and restart the AppStream session.  Even then, there is no guarantee that the performance will be any better when it comes back up!

Overall, it's been quite frustrating to get the setup to a reliable and usable state.