caching performance

[JoshWhite]

I recently recached my basemaps and now I have having a lot of issues with poor performance.  I'm using the Flex Viewer and the areas that were within the AOI seem to load more slowly that previously.  Really the main thing I changed was to move my data from a file geodatabase to SDE and my AOI was a smaller area but the cache settings were unchanged.  I would note that the previous cache was done in 10.1 and the new one was done in 10.2 if that makes any difference.

[WilliamCraft]

Is ArcGIS for Server 10.2 on the same machine on which 10.1 was previously installed, or is it on a new machine entirely?

[JoshWhite]

The same machine

[WilliamCraft]

Besides the Caching tab, how about your other map service settings for the cached service(s)?  Is everything the same at 10.2 as it was in 10.1 for the Capabilities, Parameters, Pooling, and Parameters sections?  As you mentioned, the caching settings are exactly the same at 10.2 as they were in 10.1 so that shouldn't be an issue as long as you're positive this is the case.

[JoshWhite]

I didn't make any additional changes, it's almost as if the cache didn't finish in the AOI even though the status said it did.  I do have Create tiles on demand checked but that was also checked before.

[WilliamCraft]

I do have Create tiles on demand checked but that was also checked before.

The statement above implies that tiles haven't been pre-generated; instead your tiles will only generate when a user goes a particular extent for the first time.  Setting your cache to generate tiles on demand will use more of your server's resources to generate the tiles, which could hinder performance for everyone.  But once a tile is generated on demand, tiles in that area should draw much faster on subsequent requests.  I don't recommend doing this for the entire cache; instead, do this for light-traffic areas and pre-render tiles for heavy-traffic areas.  Although a bit older, this article discusses some best practice concepts for caching on demand:

http://blogs.esri.com/esri/arcgis/2008/09/18/strategies-for-on-demand-caching/

it's almost as if the cache didn't finish in the AOI even though the status said it did

Stepping back for a second, I believe you initially said that you were having poor performance with rendering the tiles.  The statement above suggests to me that you are having issues rendering certain tiles at all.  Is it one or the other, or both?  What does Fiddler return when you having it running during tile requests?  If everything is exactly the same in terms of your cache tile settings when creating the cache as well as in terms of your service settings, I can't think of any reason why your cache tiles would perform poorly.  I can see them taking longer to get created (since you said the AOI is now larger and your data got moved to an enterprise geodatabase), but that shouldn't affect draw time if the tiles are pre-rendered.  However, I'd like to understand more about the answer to the first question I have at the very top of this response first.

Why it is slow for you at 10.2 but not at 10.1 is a mystery to me at this point in time.  However, it feels like the culprit could be the data store change rather than simply the 10.1 to 10.2 upgrade.  Data often performs slower from an enterprise geodatabase than from a file geodatabase.  This might just be your problem.

[JoshWhite]

As a reply to your first statement.  I have chosen an Area to cache that is high traffic, the create tiles on demand is only for those areas that fall outside of this AOI.



Now for the second part.  All of the tiles within the AOI eventually render.  And those outside do too just takes a bit longer.  Your probably right about the switch to an enterprise database however, why would that affect the cache?  I did just compress it just now too as well so we'll see if that helps. 


Fiddler doesn't show any errors but my most recent test was just fine, who knows maybe the Compress is all it needed??

[WilliamCraft]

the create tiles on demand is only for those areas that fall outside of this AOI

So you have set tiles to cache on demand for only a portion of the AOI rather than all of the AOI it sounds like.  That's not what came across in your previous posts but maybe I read too much into your statement.  The only way I could see tile rendering performance be related to the data store (e.g., changing from file GDB to enterprise GDB) is if you were going to tell me that initial tile creation is much slower than before but that once they are created no more issues exist.  If that's not the case and tiles are slow no matter how many times they're requested, then there doesn't seem to be a performance issue associated with on-demand caching and changing the type of data store.  You should probably consider opening an Esri ticket.

[TimCollyer]

I was just about to make a similar post.

I have two identically spec'd servers (virtual environment). 2x CPU. 6GB RAM.

My "old" one I have ArcGIS Server 10.0. I have a map service published there that uses ArcSDE Connections.

My "new" one I have ArcGIS Server 10.2.1. I have converted my map service to use direct oracle connections (using oracle instantclient 11.2).

I run an identical ManageMapServerCacheTiles job on each one.

My initial investigation seems to suggest that the new server (10.2.1 with direct connect) appears to be about twice as slow. It takes about 30 minutes as opposed to 15 on the old one.

There are still some variables I am yet to eliminate (the big one being background load on the database), but it appears that the caching performance is well down.

Has esri commented on this?

[JoshWhite]

I haven't seen anything from esri on this.  Since I compressed my SDE it seems to have improved, I cannot explain what else might have happened.