Mix dynamic and tiled service on ArcGIS Server 10.3.1

[YiQi2]

Hello:

My question is about improving a feature service performance on the ArcGIS Server. I publish a large polygon shapefile, which is census track level data for the whole US. It takes a long time to load the whole map when the web application starts up. My idea is to build cache at the larger scale (nation or state level), so the map can start up faster at larger scale. As users zoom into smaller scale, like county or city, the map will display as dynamic service (don't build caches at smaller scale). Is it possible to consume the same service in this mixed style, or are there any other ways to improve client performance? I greatly appreciate your guidance. Thank you in advance!

[JakeSkinner · Accepted solution]

Hi Yi,

I would recommend creating two services:

1.  A tiled service cached at the desired scales (i.e. country)

2.  A dynamic service that is only visible at certain scales (i.e. county, city)

[YiQi2]

Hi Jake:

Thanks for your reply! I guess your solution might solve the problem but lead to another one. If I add two services into the map, the layer list widget will show two services (but essentially the same map). This is kind of anoyying. Is there a way to solve it?

[JakeSkinner]

If you are using the Web AppBuilder Developer Edition, this looks like it can be accomplished.  See the following thread:

Re: Can I remove layers from my LayerList in a WAB created map?

[PF1]

Hi Yi,

We have the same scenario.  We've been building cached services to level 14 (~1:36K) which takes about 32GB of disk storage (processing was 8 hours, but we beefed up the server significantly and got that process down to 2 hours).  Dynamic service at full extent is terrible performance (30-90 seconds).  Since the bounding box is so small at level 15 and below (much less data is returned that needs to be fetched, processed, and rendered) the performance is sub-second on the dynamic requests.

An example cached service: https://gis.blm.gov/arcgis/rest/services/lands/BLM_Natl_SMA_Cached_with_PriUnk/MapServer

And Dynamic Service: https://gis.blm.gov/arcgis/rest/services/lands/BLM_Natl_SMA_LimitedScale/MapServer

Consumed in example application: https://eplanning.blm.gov/epl-front-office/eplanning/lup/lup_register.do

You can see in the network traffic that the requests switch from the cached service (level 14) to the dynamic service:

Although this has been working pretty well for us, some of our business programs want to be able to enable and disable layers in the cached service.  Unfortunately the have not been able to do that so we have had to build multiple cached services for their use (each service has layers enabled/disabled based on their requirements):

Unfortunately this approach requires us to store the cache 3 times (at ~30GB each) and have to re-process the data 3 times each quarter also (~2 hours each now). Cost of doing business...

I would be in favor of a service having the ability to cache to a certain scale (level 14) then automatically switch to a dynamic request when it is not cached below that level!  maybe a post to ideas.arcgis.com is in order...

Thanks to Dan Huber​ who helps us with this process! 

[RebeccaStrauch__GISP]

Patrick, can you expand on

but we beefed up the server significantly.

  I'm on a VM machine, caching an image serer (which in itself speed things up), but our network folks were trying to help speed things up by maybe reallocating some cores (without hurting other processes on the network).  I was wondering what you did, so maybe I can pass the info to them.  Thanks.

[PF1]

Hi Rebecca,

We cache our services in a separate ArcGIS Server Site (built only for caching), then move the cache to our test environment where the data people can review and approve the cache.  Once its approved we 'release' it to production.

The original cache server was a measly 1 vCPU with 4GB RAM.  Cache build took over 8 hours.  We acquired some new beefy hardware with GPU's attached that are intended for a XenDesktop deployment for ArcGIS Desktop, Imagery software, and ArcGIS Pro.  That project has been moving slower than we like, so we started using a small portion of that hardware for our cache builds... we presented 28 vCPU and 100GB ram on a VM to windows 2008 and the cache build is now around 2.5 hours with 27 instances.

[RebeccaStrauch__GISP]

Wow...thanks for the info on the vCPU's/ram.  Not sure that I could even get close to that but short term/weekends they may give it to me.  Just an FYI -- without image server extension 10 scale 16M -> 24k ...a good 8 weeks.  With Image Server Extension...14 scales 16M -> 5k, I think we are looking at a couple weeks, but I think we are at 4x1 CPU....so maybe....

edit: btw, to put the timing in perspective... our extent is Alaska, in Alaska Albers.....also crosses 180°  which always makes things soooo much more interesting. (not that it affects the caching time)