Incremental Cache Update Performance

[MichaelVolz]

To All ArcGIS Server Users:

I have been using AGS since 9.3 and the cache performance dramatically improved between 9.x and 10.0.  I have upgraded to 10.2.2, but have not cached any mapservices due to the performance improvement of the dynamic mapservices.  Now I have an application that needs some of the layer's cached to improve the performance of the application.  I have modified my python script to update the cached mapservice from 10.0 to 10.2.2 because the python tools for caching have changed.  Unfortunately, now that I have run the incremental cache update on layers that are identical to my 10.0 environment I am finding that the incremental cache update is taking twice as long (I would have expected either the same length of time or at least a slight improvement).

Has anyone encountered a longer incremental cache update time between an older version of AGS (e.g. 10.0) and a newer version (e.g either 10.1 or 10.2.x)?

If not, would anyone know what I can check and change to improve the performance of the incremental cache update?

Any help or feedback is greatly appreciated.

[MichaelVolz]

More information about my environment.

In my AGS v10.0 setup, there is only 1 server and the exploded cache files are being written to the server's local c-drive as per the default AGS installation.

In my AGS v10.2.2 setup, there are 2 load balanced servers and the compact cache files are being written to a network storage location and not onto the 2 server's local c-drive.

Would the I/O of saving the cache files to a network location explain the increased incremental cache update time in the v10.2.2 environment compared with the v10.0 environment?

[MichaelVolz]

Just bumping up this discussion to see if anyone from ESRI would have an explanation on why the incremental cache update takes twice as long at v10.2.2 using a bundled cache compared to an exploded cache in v10.2.0.

[MichaelVolz]

Additional information regarding this issue after speaking with ESRI representative.  I performed the same process as the python script with ArcCatalog caching tools and received completely different results.

          ArcCatalog     Python

Scale     1000          1000

Time     35 secs          11 mins

Tiles     384               50,688

Scale     2000          2000

Time     31 secs          6.5 mins

Tiles     384               14,144

It appears that the area of interest (AOI) is somehow being seen as much larger when run in the python script compared to the ArcCatalog tool as both methods are pointing to the same polygon file gdb feature class for the AOI polygon.  I will note that the polygon is a multi-part polygon where different areas of a county have changed.

[MichaelVolz]

I discovered why the incremental cache update was taking longer than expected at 10.2.2.  The Help for this tool in ArcCatalog 10.2.2 shows the parameters in the Syntax portion of the Help in the wrong order.  The Area of Interest parameter was swapped with the Update Extent parameter.  These parameters were in the correct location in the python scripts below the Syntax portion.

The Help for this tool has been fixed at 10.3 where the syntax is consistently correct throughout the Help for this tool.

[RebeccaStrauch__GISP]

I think that is worth a "correct answer" since you've documented it and no one else piped in. I'll probably run into this at some point and it's good to have it here.

[MichaelVolz]

Make sure you apply the map cache patch which makes incremental cache updates possible without the issues of the bundles being locked so you are unable to update the bundles under load.