I am asking this question because I am at a loss and dont have a good enough understanding of all the underlying operations going on 'under the hood' of Windows/Arcgis.
- What is the root cause of fgdb performance issues on network drives?
I have done some testing regarding performance of fgdb's vs shapefiles, network vs local drive.
B: drive is my local computer drive. K: drive is the local network drive for geodata.
Method: I use 5 point feature classes with random generated points, all within the same extent. The feature classes have respectively 100 000, 10 000, 1000, 100 and 10 points. The left side of the diagram shows time used while transferring higher number of points, while the right side shows time used while exporting feature classes with 10 points (all duplicates of the 10 point file). The Y-axis is time in seconds.
Note that all results on my local computer drive are pretty much flat compared to transfers on the network.
Monitoring the task manager on the network tab on my computer, i can see that there are large periods of network 'silence' followed by a short burst of activity (1 featureclass), then followed by anoth 40'ish seconds of nothing.I am asuming it is because of schema locks, But I would like to know what causes it and what can be done to prevent it.
I work within a very large government organization (~1300'ish ArgGis licenses) with several regional offices and a small'ish central IT group. We are still working in ArcGIS 9.3.1, but are going to upgrade to 10.3 in the fall. We are not a GIS-dedicated organisation, GIS is only a tool for supporting the decisionmakers here. Only my colleague and I are GIS-engineers in regional office (500 employees, 70 Arcgis licenses).
We have a central database (SDE on Windows Server 2008 R2 that contains most data on a national level) and a local (physical server) that is dedicated for geodata within each regional office. Certain datasets (large raster datasets, DEMs) are divided on a national level and also stored on the local server in the regional office.
The infrastructure is set up by IT. Geodata is only a small part of this, so the geodata considerations do not always take priority with the entirety of the IT system (i.e. turning off opportunistic locking is not an option).
Due to our large organization and legal requirements, working on the local computer drive should be avoided due to lack of backup. In theory, all geodatawork should be done on the geodata network drive (local in-house server).
When we upgrade to ArcGIS 10.3, with the easy option of 'let this be my home directory for this MXD' option, I would very much like to use the filegeodatabases to help keep all data organised, as there are several new MXD per week with plenty of scratch data floating around everywhere. However, with the performance issues that I have found, It feels we will still be stuck with shapefiles and a hard-to-keep-organized data environment.