roktech blog

Debugging ArcGIS Server Performance Issues - Part 2

Posted by Jason Harris on Jul 27, 2015 1:08:28 PM

arcgis server

Here is part 2 of the series in which we review ArcGIS Server Performance Issues.  If you missed it, best to read Part 1 first.

So, we last left off (yeah I realize its been quite some time, but hey, I'm busy ya know) I showed you how to look at the REST requests being sent and returned from the server.  Again, this is should be your first stop when looking at ArcGIS Server performance issues.  You'll be able to see the specific requests and its response.  For example, why is that particular request taking so long to return?  Well, turns out there could be dozens of reasons, but my top trouble makers are usually:

  • Too many records returned in a query
  • Unnecessary fields (data) included in the query.  Do I really need to return all these fields?
  • Excessive geometry.  Did I need to return the geometry?  Perhaps I should consider generalizing my features to cut down on the number of feature points returned?  Generalizing features can have also have a dramatic decrease in map generation time.  Only show as much detail as you have to.

So those are the obvious ones.  I can figure those out pretty quick.  But, what if there is no apparent reason for the slowness on the client?  What about when a map image just returns slow?  Well, now its time to hit the server to give it a closer look.

Once I get on the server, first thing I do is open up ArcMap and fire up the MXD that was used for the map service in question.  Generally speaking, the speed at which the map draws in ArcMap is the same speed at which it should draw via ArcGIS Server. So, start by turning off all the layers in the MXD and one by one, turn them back on, keeping note of how it takes that map to draw.  Ah ha - you found it.  Its that parcel layer isnt it?  Well, truth be told it could be any layer for lots of reasons, but for the sake of the example, lets just say its the parcels that are showing the slowdown.  So, now what?  Well lets turn to our bag of tricks and dig in.

The very first place I look is whats the datasource.  This is where debugging can quickly turn into a Choose Your Own Adventure Book (remember those?).  If its ArcSDE, we have to check the database, file geodatabase, well gotta look at those.  The vast majority of slowness issues, in my experience, trace back to the database/SDE. Ok, so what do I look for?

  • Is the layer compressed? This can be a huge slowdown if it hasn't been lately.  Make 100% sure that you have exclusive access to this layer (ie shut down any map services using it, kick out your pesky users, etc).  Then, run that compress.  See it helps.
  • Does the layer have a join of some kind or is it a spatial view? Ah yes, another big one.  Make sure your join fields are indexed properly.  I cannot stress this one enough.  A table join (in ArcMap) or a spatial view join without indexes are dogs.  Slow you down to a crawl.  Most of us out there are GIS folks and don't know much about how data is stored in a database, so  if you have access to a DBA, use them.  Bring them some cookies first, then ask real nice and play stupid.  Works every time.
  • Rebuild those spatial indexes (via ArcCatalog).  I don't see this much, but its come through for me a few times.  Definitely worth a look.
  • How is the database performing in general?  I've seen a couple of bad queries bring a 16 core machine to its knees.  Make sure all is well on that front.  Check CPU, RAM utilization, etc.  Diagnosing database server issues is an entirely different beast, and I'll leave that for another post.  But for our purposes now, just check to make sure some other process isnt pegging the server & you have enough RAM.

But, you know, sometimes you don't have the time to properly diagnose issues with the database (maybe the DBA doesn't like choc chip?).  If thats the case, for a quick fix, I will just dump the feature class to a local file GDB, change the datasource in the MXD and republish.  That will buy you some time until you can get in there and figure it all out.

So, these were the obvious things that are generally easy to diagnose.  Next in the series, we'll take a look at some of the more advanced performance tools you can use, such as SQL Profiler to find those bad queries, and PerfMon to closely monitor hardware performance.  I'll also give you some tuning tips to make sure your map services are being served as fast as possible.  Until next time...


Topics: Application Development, ArcGIS Hosting, ArcGIS Server, ArcGIS Server Hosting, ArcGIS Server REST, ArcSDE, ArcSDE SQL, Cloud, GeoDatabase, GIS, Performance, ROK Technologies, Uncategorized

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all