Thanks Mike, that was very helpful information. From the logs, it does appear that the service is the bottleneck... a majority of processing time resides in the processing of REST requests. One such instance took 6 seconds and returned 3MB of data, although other sizable response packages were processed in tenths of a second. So, I'm now thinking that having so many picturemarkersymbol templates (hundreds) in the package's layer renderers is a best practices no-no. And these make up a majority of the 11MB package size (uncompressed). Experimenting further, I've decided to remove all picturemarker symbols from the package and instead have my map app load these directly from image files via the Runtime client APIs, thereby bypassing the service with respect to the serving of these templates. Unfortunately, this requires that I first programmatically re-define the underlying layer renderers on the client side, since the ones predefined in the package cannot be mutated on the client to dynamically apply the API retrieved symbol templates (via UniqueValueRenderer::Infos). Small price to pay. After applying the changes, a preliminary run of my client has the map and symbology templates now loading in 1/8 the time as compared to using the original map package that contained all picturemarker templates! FYI: As a fall-back to the above solution, splitting the original map package into 4 smaller packages halved the map load time. I think this was thanks to now having 4 map services, versus 1, simultaneously crunching the data. The only negative was that one of these services sometimes failed to start due to an access/permissions ArcGIS exception. Possibly a resources issue or thread contention? Anyway, I'm glad that the other much cleaner solution worked out. Thanks for helping to point me in the right direction! Greg
... View more