Map package with only 8 layers and no feature records is very slow to load

Question

Will try to keep this brief.  I have a map package that takes almost 1 minute to load into my client map via a local map service (no network - both client and server on same beefy machine).  The package contains 8 feature layers, each layer hosting a unique value renderer, each renderer containing about 50 tiny pixmap marker symbols.  There are no feature records or anything else in this package.  Removing a chunk of these marker symbols greatly improves load performance.  Anyone know why the pixmap markers require so much processing?  I'm using Runtime 10.2.  Thanks!

Greg

MichaelBranscomb · Answer

Hi,

Glad you found an approach that works for your app.

RE: "one of these services sometimes failed to start due to an access/permissions ArcGIS exception. Possibly a resources issue or thread contention?"

Did you create 4 separate MXDs, each with a different name and repackage each one? Note renaming the mpk file names themselves isn't enough, they need to be packaged as unique names. Otherwise there is the potential for a conflict as each package is unpacked.

Cheers

Mike

GregYacoub1 · Answer

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

MichaelBranscomb · Answer

Hi Greg,

The first time you start a LocalMapService from a Map Package (.mpk) it is unpacked to your user profile (unless you've set the LocalServer.AppDataPath property). That can take a little time, depending on the size of the mpk. But in this case, it sounds like your mpk will be just a few hundred KB if it contains no data. Subsequent attempts to start the service (i.e. the next time the user launches your app) would be quicker because the mpk is already unpacked. The only exception to that would be if you have repackaged the mpk and re-deployed, in which case it would be recognized as an update and unpacked again.

It sounds like the time taken to start the service may be in actually parsing the MSD file (internal Map Service Definition within the mpk) and start the local map service... you can enable logging and check the log file to see what's happening there.

- Run "C:\Program Files (x86)\ArcGIS SDKs\DotNet10.2.7\WindowsDesktop\bin\arcgisruntime10.2.7\LocalServer64\bin\LocalServerUtility.exe"

- Check the box to enable logging:

- Run your app

- Switch to the Log Files tab and click refresh - you see a log file has been created.

- Double click the log file to open.

- Review the messages from the LocalServer.

- You might be able to discern where the delay is from the log file.

It could well be the complexity of the layers / renderers / picture-marker-symbols so it sounds like you're on the right track with your investigations already.

Cheers

Mike