New Map Service Cache Size

1784
14
03-24-2017 07:53 AM
DaveTenney
Occasional Contributor III

All,

   i was just curious if how the way things are cached in 10.3.1/10.4.1 vs 10.2.2 will cause the cache to be larger in size?

we have a map service that we wanted to cache, nothing has changed other than the version, we upgraded from 10.2.2 to 10.4.1

10.2.2 cache size 96gb

10.4.4 cache size 125gb

   we have havent changed a single thing, not one. we havent changed anything in regards to the map itself and its data, nor have we changed anything in the settings of the service when we publish.

thanks

Dave

0 Kudos
14 Replies
MichaelVolz
Esteemed Contributor

Did you try to just create an empty cached service at 10.4.1 and just copy the cache from 10.2.2 to see if that old cache would still work in 10.4.1?

0 Kudos
RebeccaStrauch__GISP
MVP Emeritus

I have never seen the size of the cache get larger, but I typically do as Michael recommends and copy the 10.2.x cache from an old machine to new.  Or, if upgrading in-place, that is on same machine, before updating I move the caches to a temp folder and then move back after the upgrade...actually speeds it up a bit.

i skipped over 10.3/10.4, but have been testing moving caches from 10.2.2 to 10.5.1.  My old workflow for this did not work as it did beteween 10.2.x and 10.3.x (on a test server).  In the past, I did as Michael suggested by creating the service and a blank cache (for folder structure) then I would copy the cache over and restart the service. All was good.

Theis process did not work with 10.5 and might be the same issue with 10.4. Instead, I copied the cache over first, with the folder name changed, if necessary to match the service name (I needed to changed mine).  THEN I created the service with the matching name and it recognized the cache in the properties. However, for the cache to work, I needed to use the upgrade cache tool.

The reason for this is that 10.2.x used the compact  bundle/bundlex format.  The compact version with those tow files combined into just a .bundle file was introduced in 10.3 but could still read/recognize the 10.2 compact format.  If not sure about 10.4 but 10.5 will not recognize the 10.2 bundlex compact version at all...other than in the upgrade tool.  But if you set up the blank 10.5 structure and copy files in, it will not.

again, not sure about 10.4, or why the size would be different, but in case it is related to the compact format changes, I thought I would mention it.

DaveTenney
Occasional Contributor III

 Today support confirmed that starting with 10.3.1 the way bundles are created it would cause an increase in size. Support was not able to confirm at the time if the same process was used in 10.4.1 that was in 10.3.1 but would look into it. We also tested this as we still have a vm running 10.2.2 using the same map and same data as our 10.4.1 vm. we published the map and build only 1 layer, see below:

10.2.2    
 layertilessizeexploded
 125602.38mb560 files
10.4.1    
 layertilessizeexploded
 126902.72mb690 files

as you can see there is a difference, at layer 12 not much of a difference but once we get to layer 19, were talking GB's worth of difference. again....same mxd, same source data, same publish settings. 

dave

RebeccaStrauch__GISP
MVP Emeritus

So, sounds like you original question re would the cache be larger is yes.

i see you are showing exploded caches.  Any reason you are not using the compact formats.  Much smaller caches overall (whether 10.2 or 10.3+ version) and many fewer files to copy between machines/folders.

only down size I see re the compact versions are the differences between the versions, and that a 10.2.x client could not read the 10.3 compact format directly (i.e., as a raster set, bypassing any service).  But if all you clients are 10.3.+, it shouldn't matter, unless running into the issue I mentioned in my first comment.

0 Kudos
DaveTenney
Occasional Contributor III

we exploded the level so we could visually see what area was being covered in 10.2.2 vs 10.4.1. 

we only use compact, but for diving into this issue we wanted to see as much as we can, since you can't really see much with the compact other than how man bundles were created. when we exploded the cache we were able to see that there were 5 extra folders created in 10.4.1 vs 10.2.2.

the issue really is we told the client that map service 1 and 2 take an "x" amount of space. those services were built using 10.2.2, now that we want to upgrade to 10.4.1, the services are being built differently. so now "x" has increased, we are waiting on ESRI to see if they know what the expected % increase in size is.

dave

0 Kudos
MichaelVolz
Esteemed Contributor

Dave:

Besides the increase in space of the cache at 10.4.1, have you encountered any other serious issues with the use of the cache in 10.4.1?  Have you tried to also create a compact cache with the same map service?  I ask because I am still running AGS at 10.3.1, but my organization plans to upgrade to a new version this summer.

0 Kudos
DaveTenney
Occasional Contributor III

Michael,

    we only publishing using the compact format, we only exploded one level of a cache for testing reasons to see what the area was that was being covered. we compared the exploded level from 10.2.2 vs 10.4.1, otherwise all of our services are always published using the compact cache.

    we have run into a lot of issues, most of these i think are not unique to 10.4.1, i think they are more of just the typical bugs that seem to travel from one version to the next!

      1) basic ArcPy functions not performing as expected

      2) ArcGIS server manager is shotty at best (im not sure why ESRI hasn't spent more time on this)

               my suggestion to you is to never solely rely on the server manager!

      3) I would be cautious of ESRIs claim of "in-place" upgrades!

               a) this does seem to work ok for desktop

               b) be very cautious with your approach to upgrading server!

disclaimer: i am only one drop in the esri bucket, im sure many many others have upgraded with no problems, and everything has worked like a charm. so please take my input for what its worth.

dave

0 Kudos
MichaelVolz
Esteemed Contributor

Dave:

In terms of your issue with AGS Manager, are you using Chrome 54+ as your browser?  There are several issues with Chrome and AGS Manager so I would suggest using IE11 - examples include problems registering database connections (BUG-000099629) and problems displaying statistics on the mapservices (BUG-000101518).  There might be even more issues with Chrome 54+ and AGS Manager that I have not encountered.

0 Kudos
DaveTenney
Occasional Contributor III

The problems we were noticing were easily recreated in all browsers...

         the big problem was the Manager interface was not in sync with the services. we could recreate the issue of a service appearing as stopped in the manager but was actually running and could indeed be accessed. we were also seeing the opposite of this. we were seeing this in 10.2.2, 10.3.1, and now 10.4.1 so its hard for us to rely on the manager interface much for certain things.

dave

0 Kudos