How many layers are too many layers in ArcMap?

Question

I work on ArcGIS using a Citrix virtual software connection at work. It is dreadfully slow at times, and without any changes to the MXDs I'm working on, one minute ArcMap can be operating at a reasonable rate, and then the next minute it can slow to a crawl. The IT Department believes the cause of the problem is too many layers in my map. I have a hunch the problem may instead be hardware or software configurations, or just the fact that we're using Citrix in the first place.

Anyways, I have, in my standard MXD that I use for editing, 57 SDE layers and 2 file geodatabase layers. The vast majority are layers I need to check for editing. I have to check to see if any data exists for each of the layers because they need to be edited and QC'd for each pipeline construction project. Only a few layers are basemap layers that I need to reference on a regular basis.

The IT Department wants me to reduce the number of layers I'm using to 10. In an ideal world, this would be fine. But in the real world, it isn't practical. With such a suggestion, I'll have to use some 5 different MXDs just to carry out an editing task for a given project. I've experimented with using only 10 layers and it is severely limiting. I lack the context of my data with relation to other data, and I have to revisit the same area multiple times just to make sure all of the data has been updated. All this for only a slight improvement in performance and a modest reduction in the number of crashes while editing.

So I have to ask, is there an ideal number of layers? How many is too many?

Answer 1

I used to work in that exact same environment (the exact same one!). I have not done any benchmark testing but my sense of this is that number of layers in the project doesn't have much effect by itself.

In my experience the labeling and number of features is a much bigger issue than the number of layers (especially if many are turned off). I used to have the labeling toolbar enabled and would often pause the labeling. That seems to improve the performance incredibly. Having layers in the project that were unchecked in the TOC, seems to have no negative effect on performance. I could be wrong, but IMO the number of layers is sort of a red herring.

My recommendation is to pause labeling ( which is the most convenient approach) or turn off labeling of features altogether.

Answer 2

I would first check out Best Practices Using Citrix XenApp and ArcGIS, a guide put together by ESRI.

For a previous client, I went through quite a bit of performance troubleshooting with ESRI and our Citrix environment. Below are the highlights from those conversations:

I'm assuming you are going to be making edits in a tight area (zoomed in pretty close). Setting up your map so that you have most of those layers turned off until you zoom in close to that level will help out with performance.

MXD Doctor is something else you may want to run to see what items might be causing problems.

Make sure that ArcGIS is actually installed on the Citrix server itself and not just mirrored or streamed.

Our biggest slowdown seemed to be caused by printers--once we disabled the printer capabilities (and autoconnection), we connected much quicker and noticed less lag time (see this ESRI newsletter for more info). This did, however, make it so that we had to export our maps to pdf first then print, but with 90% of our work being editing and analysis, nobody seemed to mind.

59 layers is quite a lot, if you are able to knock it down, that would help. As suggested by @jbchurchill, take a look at your labeling. You should also look at any custom symbology you might have.

Answer 3

I have some experience troubleshooting performance in GIS systems, including on citrix. Your problem can be anywhere and likely a combination of factors. Talk to your Esri rep for pointers.

I recommend you read this:http://www.wiki.gis.com/wiki/index.php/Software_Performance#Use_MXDPerfStat_to_measure_display_complexity

Labeling, using Feature cache and cached basemaps are all good practices.

There is also a newer tool you can try that is more user friendly called perfqanalyzer https://blogs.esri.com/esri/supportcenter/2014/02/03/calibrating-arcgis-performance-with-perfqanalyzer-new-build-available-for-download/

Answer 4

Just thought I'd jump in that I work in a company that have a bad practice with MXDs using them as almost file servers for data. To give you an idea we have MXDs with over 1000 layers. We worked with some consultants that reccomended 650ms per layer for a map to open is reasonable meaning some can take 14mins to open up for us! Its not good and definitely isnt optimal but I wanted to let you know there are others than suffer too!

We have recently moved to EGDB and that hit the performances massively. I found that enabling feature caching made a big different along with ensuring the EGDB has proper maintenance (analysing, indexes, compress etc)

I second MXD doctor to remove all of the old paths connecting to data, try deleting the template map. MXD perf stat is a powerful tool that I feel I havent utilised half enough due to my lack of cmd skills.