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!