Which should I choose between MMPK and MPKX(LocalServer)

684
6
Jump to solution
06-09-2020 08:56 PM
EricJing
New Contributor III

I am integrating ESRI map into our product, we use it as offline map. Now we have two solutions,  MMPK and MPKX(LocalServer). From arcgis document, I already know mmpk is designed for offline map. And I made a test, mmpk has better performance on QueryFeaturesAsync than mpkx(localserver). We have a big amount of data in FeatureTable( around 30,000 features), so the performance is important to us. But mpkx(LocalServer) has editing feature capability, which could be requested by our customers in future, so it is tempting to us as well. The customers expect not to regenerate mpkx very often.

I am struggling which solution I should go with? Or maybe there are other better solutions?

(BTW, enterprise level server is not an option, the customer cannot afford) 

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
dotMorten_esri
Esri Frequent Contributor

I would say this performance difference is more or less expected. If the MMPK can do what you need, I wouldn't even consider running local server. It's mainly meant to bring in the full power of the entire arcgis system, and done by basically running a slimmer version of ArcGIS Server in-process - that includes a much larger runtime to load and a lot more data serialization which has significant overhead and limits to how much data can be pulled at a time. You get a LOT of power with this approach, but it does come at a cost.

As Nick mentioned, the MMPK uses direct-read of the data right from the rendering pipeline, so you'll see much better performance and faster load time.

View solution in original post

6 Replies
Nicholas-Furness
Esri Regular Contributor

Hi.

Some thoughts, and a third option that could possibly help:

  • MMPKs can be used by all Runtime SDKs whereas MPKX and Local Server are suitable for targeting Desktop apps built with Runtime since it relies on Local Server and Local Server only supports Windows and Linux on Desktop. If that's what you're targeting, great, but I wanted to make sure you were aware of this depending on what you were planning on targeting.
  • When you use an MPKX it's going through Local Server, so I'm not surprised you see a bit of a performance boost using MMPKs where you're working directly against the file system. I wouldn't expect it to be huge to be honest, but there is always some overhead with hitting the Local Server.
  • You might consider the Preplanned Offline Map workflow. Whereas MMPKs are created by our Desktop tools and can be deployed to devices (hence no editing - there isn't a pathway to process edits back to the data sources), the Preplanned Offline Map workflow allows you to work with a web map and hosted data and download that to your device as an offline map. This supports editing since the downloaded data is associated with data services. When you need to, and you have a network connection, you can sync edits on a device with the hosted data service(s). High level, you author a web map with data layers, determine one or more areas of the web map to be packaged up once, and many devices can then download and use that.

The preplanned workflow is pretty powerful because it's supported by ArcGIS Online (Enterprise not required), it supports editing, and it is scalable.

You can find out more about your options in these technical sessions:

Hope this helps.

Nick.

0 Kudos
EricJing
New Contributor III

Hi Nick,

Thank you for suggestion...

1. Our product is based on windows desktop.

2. "I wouldn't expect it to be huge to be honest, but there is always some overhead with hitting the Local Server."

Actually, I made a test on performance between mmpk and mpkx.. 

I use FeatureLayer.FeatureTable.QueryFeaturesAsync(qryParams) to load 24,599 features with mmpk and mpkx.

mmpk: 0.57 second

mpkx: 27.11 secons. 

The performance difference is huge... I even feel unbelievable. I am afraid if I had some wrong configuration.

Do you have bench mark for this? Can you share?

3. In order to work with Preplanned Offline Map workflow(ArcGIS online), what license should we have?

0 Kudos
Nicholas-Furness
Esri Regular Contributor

Hi Eric.

1. Excellent. Thanks for confirming.

2. Interesting. TBH I don't have much experience with Local Server, but I'll raise this with the team to see if this is expected. It could be something to do with how the data in the MPKX is indexed?

3. For Runtime: any editing (except of completely public, unsecured data) requires Basic or higher. If you are not editing, you can use Lite. To create and manage the web map (supporting editing or not): you will need a suitable ArcGIS Online user account type (Creator or GIS Professional can create web maps).

Hope that helps.

Nick.

0 Kudos
Nicholas-Furness
Esri Regular Contributor

WRT the performance difference, is the data being packaged into the MPKX or might it still be being referenced in the source enterprise geodatabase? If it is being packaged, if you query again is it quicker (I wonder if Local Server is unpacking the MPKX and that is contributing to that 27.11 seconds)?

If not, Michael Branscomb might have some more thoughts.

0 Kudos
EricJing
New Contributor III

It is packaged into MPKX. Querying again is not quicker...LocalServer unpack mpkx into app data folder.

I did another test, changing FeatureRequestMode to Manual, then using PopulateFromServiceAsync to load into local cache, then QueryFeaturesAsync gets similar performance to mmpk. But PopulateFromServiceAsync takes around 20 seconds. I guess most time is spent on serialize/deserialize in LocalServer, since the data is transmitted in Json format.

0 Kudos
dotMorten_esri
Esri Frequent Contributor

I would say this performance difference is more or less expected. If the MMPK can do what you need, I wouldn't even consider running local server. It's mainly meant to bring in the full power of the entire arcgis system, and done by basically running a slimmer version of ArcGIS Server in-process - that includes a much larger runtime to load and a lot more data serialization which has significant overhead and limits to how much data can be pulled at a time. You get a LOT of power with this approach, but it does come at a cost.

As Nick mentioned, the MMPK uses direct-read of the data right from the rendering pipeline, so you'll see much better performance and faster load time.