topic Re: caching performance in ArcGIS Enterprise Questions

caching performance

JoshWhite — Thu, 27 Feb 2014 14:40:38 GMT

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.

Re: caching performance

WilliamCraft — Thu, 27 Feb 2014 16:54:21 GMT

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?

Re: caching performance

JoshWhite — Thu, 27 Feb 2014 17:05:46 GMT

The same machine

Re: caching performance

WilliamCraft — Thu, 27 Feb 2014 17:22:09 GMT

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.

Re: caching performance

JoshWhite — Thu, 27 Feb 2014 17:43:25 GMT

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.

Re: caching performance

WilliamCraft — Thu, 27 Feb 2014 17:51:56 GMT

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.

Re: caching performance

JoshWhite — Thu, 27 Feb 2014 20:00:10 GMT

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??

Re: caching performance

WilliamCraft — Thu, 27 Feb 2014 20:07:09 GMT

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.

Re: caching performance

TimCollyer — Thu, 27 Feb 2014 22:59:37 GMT

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?

Re: caching performance

JoshWhite — Fri, 28 Feb 2014 18:50:44 GMT

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.

Re: caching performance

MichaelVolz — Fri, 28 Feb 2014 19:10:59 GMT

How much slower are the cached mapservices using SDE in v10.2 compared to v10.1?

Would you be able to use v10.1 SDE to create your cached mapservices for a more direct comparison between SDE at both versions?

I don't know if this would matter, but have you tried using the standard Oracle Client instead of the instant Oracle Client and then compare metrics of the cached mapservices.

Re: caching performance

TimCollyer — Sun, 02 Mar 2014 21:43:51 GMT

Ok, I think I can now confirm that this really is a problem.

I started a generation of my "full" cache (I was just running some sample areas when I posted earlier).

Using 10.0 this would take about 30hrs. Running now on 10.2 we are up to over 48hrs and I think it's only about 60% through (that's a rough estimate, I run my cache over 27 different features classes and it's finished 16 of them).

My 10.2 environment is as close to my 10.0 as I can make it... The big difference (I think), is using the oracle client for direct connections as opposed to an SDE connection...

Re: caching performance

JoshWhite — Mon, 03 Mar 2014 12:17:25 GMT

My main frustration is that I kept hearing how much faster SDE would be and I switched and ran into all sorts of performance issues. The main reason I switched was to start using feature services but I'm still the only Desktop user.

Why should the data source affect caching if the database is registered as a data store?

Re: caching performance

MichaelVolz — Tue, 04 Mar 2014 15:34:39 GMT

Are you certain that it's the update to the feature class that is the root cause of the slowness that you are seeing? I ask because some of my organization's GIS web performance slowed down considerably due to increased demand and we found the router was the bottleneck which is an expensive fix. Maybe its a coincidence that you are getting heavier load on your servers and that is the real issue (This is just a theory). Do you have a means of measuring the load on your GIS server(s)?

Can you revert back to your previous setup to see if the performance has degraded there so you could rule out the different datasource as the source of the slowness?