File geodatabase in Windows networks very poor performance

[KristianHerner]

Hello,

I'll try to keep this short. I represent a large goverment organisation in Sweden. I am a GIS coordinator for the user side of the organisation and of my daily tasks is to recommend best practices, to keep performance up within the typical large organisation restraints (central SDE, network drives)

I have a benchmark script that does this:

1 - creates two file gdbs at the same location (arcpy.CreateFileGDB_management x 2)

2 - creates two empty featureclasses in one of them (arcpy.CreateFeatureclass_management x 2)

3 - exports both featureclasses with one command (arcpy.FeatureClassToGeodatabase_conversion(fcs))

4 - then exports them both again, this time one by one

When I do this on my local harddrive, i.e. my computer, it takes around 10 seconds all together to execute the script.

When I run the script on a network drive, it takes upwards of 8 to 10 minutes (!!!!!) 

 

Where do I start? Any good resources I should read? I am not a windows network specialist and I have no idea why it is like this. Any feedback is greatly appreciated, thank you.

[KristianHerner]

Unfortunately, nothing changed during my time here - it has always been this bad (4+ years) but people have been using shapefiles in general and havent noticed too much (except the usual "GIS is really slow!" and you see 20 layers with broken datasources in their MXDs, etc...). To the best of my knowledge, it has always been like this.

With ArcGIS Pro on the horizon where everything defaults to file geodatabases we need to identify the problem and solve/bypass it before we can even consider switching to Pro.

[DevinLavigne]

I'm with Kristian on this one. I have been trying to work with a geodatabase over a network and it has been absolutely excruciating.  I have tried to copy small datasets between geodatabases on my network and it takes 30+ minutes. My productivity is so poor that I now work on two things at once as simply working in GIS would allow me to get anything done.

[DevinLavigne]

I just posted two animated Gifs of me browsing directories in Pro on another thread and thought I should post them here too. Something is either not working in Pro, or I'm missing a necessary network protocol on my server adapter to make this function as one would expect.

1. Browsing a directory in ArcGIS Pro

2. Browsing the same directory in Windows

[Anonymous User]

We get the exact same experience here. We're moving to a DFSR path to a local server on the network but it doesn't look like that resolves it either. It seems there's something with Pro which slows down browsing and it's noticeably worse than ArcCatalog/Map.

[MalcolmMeyer2]

I have a GB connection to my local network Windows Server which is in my same building, and in ArcMap 10.6 & now 10.7 FGDB editing over the network is very slow and buggy. Just had some data 'disappear'. My IT team wants to know if there is a minimum or recommended network read/write speed for using file geodatabases over a networked connection or mapped drive. Also, is this even a recommended practice - using a networked drive for GIS data stored in File Geodatabases but outside of a relational/Enterprise database?

[JoshuaBixby]

Responding to your last question, is it recommended?  I can't recall ever seeing any documentation where Esri says it is "recommended."  That said, I also haven't seen any documentation where they say it is unsupported.  If hosting file geodatabases and other spatial data on network drives common?  I would say yes.  The organization I work for has its enterprise file system for GIS file-system data on a NetApp-backed network drive.

Hosting GIS data on a network drive introduces many new levels of complexity versus just hosting data on "local" drives.  There are network related issues, like latency, timeouts, etc...  There are SMB configuration issues, both on the client and server.

I have seldom heard of network data just "disappearing."  Typically, there is either an error on the server side that corrupts it (which the IT shop should be able to track down), or someone else with access to that data accidentally deletes it.

[MalcolmMeyer2]

So how do you find the performance of editing FGDB over the network? Is there any difference in performance over the network with Pro and Desktop? Finally, do you know your read/write speed to the network drive?

[JoshuaBixby]

The "performance of editing FGDB," whether locally or on a network, depends on the workflow.  Are you manually editing data using the GUI in an edit session?  Are you using cursors to bulk update data outside of an edit session?  There are so many variables at play that it is hard for someone to make general comments on finding the performance of editing FGDB data.

One of the main metrics of storage performance is IOPS (input/ouput operations per sec), especially with a shared storage environment (SAN, NAS, etc...) where there are lots of competing read and write requests.  Storage is an entire specialty within IT, and I am not knowledgeable enough to be giving advice.

To answer your read/write question at a basic level, writing a single 1 GB file to our enterprise file system (1000 MB x 1) gets around 150 MB/s throughput, writing one hundred 10 MB files (10 MB x 100) sequentially gets around 110 MB/s, and writing one thousand 1 MB files (1 MB x 1000) sequentially gets around 45 MB/s.  The read speeds are faster, but you get a sense of the scale we are dealing with.

[MalcolmMeyer2]

I am getting around 115 MB/s read and 24 MB/s write with the default test in CrystalDiskMark. The write speeds are the bottleneck in our network for sure. I recall seeing a 100 MB/s read/write recommendation for GIS use at one point either on a forum or blog, but have not been able to find it again. If there was an Esri minimum requirement that I could show to my IT team that would be very helpful, albeit this would be subject to a wide variety of contingencies depending on the types of edits as you noted above. In my situation there are three people reading data and one person editing data. 

I have a hunch that I would get better write speeds using PostgreSQL on a VPS in the cloud. That is the route I am likely to go at this point, at least for testing, and if it proves successful it means either dropping Arc for editing or fork over 20k for Enterprise : (.

[JoshuaBixby]

Although this page is for ArcGIS Enterprise, I would argue the statements apply to ArcGIS Desktop as well:  https://enterprise.arcgis.com/en/server/latest/install/windows/choosing-a-nas-device.htm.

Immediate consistency

Choose a storage device that enables files to be read immediately from any node in your site once an operation and corresponding write has completed. This disqualifies many types of distributed file systems, such as GFS and DFS.

NFS shares must be configured to ensure consistent reads and avoid using stale data caches.

Performance

Choose a storage device that performs well while incurring volumes of small, random input/output (I/O.) Consider that read and write performance can greatly fluctuate depending on the characteristics of the I/O. This is an important distinction as ArcGIS Serverand Portal for ArcGIS operations (interactions with the configuration store, cached bundle tiles, and so on) follow this pattern.

Often this means that a device that has been optimized for large, sequential reads and writes (as often occurs with imagery and video) is unsuitable for use with ArcGIS Enterprisecomponents.

If your implemented file storage mechanism does not handle small, random I/O well, you may experience significantly increased response times, or even failures, especially for administrative operations applied in your site.