Did you generate your cache based on the purple feature class? It wouldn't have generated tiles for the white space which could make up a significant number of tiles for the whole cache. The full cache would be rectangular.
The percentages are somewhat meaningless.A completed cache service could be even at 8% like some I have seen.Especially if you send a GP request at a later time, or cache is moved to an existing service.. it will never reach 100%.go into the cached folders in arcgisserver and look in the GDB, all status spatial and tabular information about the cache is there (very detailed)...You can also check cache status with ArcCatalog against the cached service (which is a finer grain) than checking through ArcServer/Manager.There are several means of adjusting the Time/size of caches.1. compressed MIXED format, down to 50%.. (these are .bundle files)2. larger tile sizes 3. More instances / processors 4. Use a cluster purely dedicated for caching.5. cache based on feature polygon, rather than map extents or full extents6. cache on demand for certain instancesjust a few I could think of off the top of my headWe have done scales down to 1:286 in some maps, or massive area maps down to L18
Define caching succeeds?"Generation not in progress" could be due to the caching is complete.This does NOT mean you will see 100% as I mentioned above, I have complete caches done showing 18%. There are a lot of variables determining the percents.Did you do what I mentioned and look at the geodatabase status? my bet is it will say SUCCESS for all records.
Jamal,I can't comment on why things might be failing at your site, Michael is in a better position to do that, but in general, you should not consider caching as the only alternative for hosting data.If you just want to serve non-complex data, like small scale polygons of provinces like the once you showed in this thread with few vertices per polygon, and with simple outline symbology, you are probably much better off serving data straight from the feature source (or a copied file geodatabase), than to create a huge cache. It will bloat storage requirements compared to the original feature data.Caches are best used for complex large scale data that may take up (tens of) gigabytes of diskspace using complex symbology, like detailed cadastral land records, high quality topographic data etc. E.g. say you have an MXD having 20 layers with large scale topographic data symbolized using layered line symbology for roads, complex hatch symbols for polygons to represent 50 different land use types and so on, dynamic labelling etc. with a re-draw time of (a dozen) seconds per screen in ArcMap. If this MXD needs to serve as a basemap layer, e.g. a background to other more dynamic data, than that type of data is best served through cached services, as you wouldn't ever be able to serve that data dynamically to hundreds, or thousands, of users at a time. Just imagine with every hit to your website, the server needing 10 seconds to render a single image before it can send of the rendered data to the user...It really depends on the type of data, and the complexity of the symbology to be used, what type of method you chose to host the data.
There are a vast amount of variables here.1st off, you say 'huge' I laugh, we have caches 10x that size even with small areas, mind you, we go down to 1:256 for some serious details.Even with a tiny area, you are going down to the 1000 level so depending on the project area, size would be expected and by using Exploded method (which creates many folder directories as well as jpgs (though the advantage to this is 'merging' caches quite easily) the size problem is exaggerated.Its again further exaggerated by using 128x128 tiles and again exaggerated using png without compression.Try re-running the cache by selecting EXTENT of the map (after of course, getting the area you want) - I have had strange problems with using features as the area of interest (however, I think this was due to custom projections being used)Use MIXED Tile format at 75 compression - you wont notice a difference! Use 512x512 tileUse Bundle format (compressed storage format)as for the estimates shown, Ive yet to see one that is accurate or really close - its a big 'guess' done by samples and algorithms.as for the 'caching never ends successful'what does the geodatabase results show you? which failures, if any are in the attribute table?Another thing you can do is create the service MANUALLY cache and send the GP request through Cache manager in Catalog to the map service when published.
Therefore, all users are complaining due to the very slow speed in panning and zooming the maps accommodated in the web application.
Jamal,I noticed one thing in your screenshots that concerns me. You have a lot of labels visible, and those labels seem to be dynamic. They are not a fixed size nor position.Dynamic labeling is very costly in most cases, and you probably want to avoid this in your web services.What you should consider, is converting your labels to Annotation Feature Classes in your geodatabase, probably best as a feature-linked version, that updates with updates to your parcels layer. As the Help page I linked says:"Geodatabase annotation is indexed spatially, meaning that it will draw and select much faster."You would also do good to set a fixed reference scale for the Annotation and labels, e.g. 1:5000, so as to have the labels scale. And set a visible scale range. As the Help says:"To maximize ArcMap display and query performance, always define a visible scale range for each annotation class so annotation features only draw when you're zoomed in enough to read their text."
Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
.png)
