mWO initialization time - identify slowness

Looks like Apps 10. If so there is a Lobby Page which shows the performance timings of the Sync. It could be that one or more entities are taking the time. Look to see which entities are taking the time to sync. If its due to data then you can add a Permission Set Filter to reduce the data and speed up the sync times.

Cheers

James

 Hi,

@James Ashmore - you mean this lobby? I've entered AppName as ServiceEngApp - same as on mobile user 

I did a new test - disconnected and connected once again so it forced full initialization. Updating data like InventoryPart... etc. took approx. 5 minutes, then there was 35 minutes with Waiting for Server on iPad.
During that time in mobile user in application there was Init waiting for GP status.

What exactly means "Waiting for Server" ? Does the iPad waits for information from server or waits for some background jobs to finish? 

Looking for VPN connections stats on iPad seems like there is no data communication during first few minutes when "Waiting for Server" and very low traffic (~1kB/s) in next minutes(I'm not sure if it's only mWO, the OpenVPN stats may show other iPad networ usage).

So I can suspect 2 things: first - a local DB is being built during that time on iPad but it seems too long or second - iPad is waiting for something to be done on server.

Finally it synchronized and in logs I can see a time gap between 13:10 and 13:40 -  in that time it was waiting for server.

What happened during this 30 minutes?

Best regards,

Hubert

Sounds like a potential problem with Grouped Push entities. This Sync Method is used in MWO to sync the Equipment Objects. The Grouped Push process should run overnight and collect the datasets for the end users. Once the end users connect they will be given the latest copy of the data sets they belong to. By default this is defined based on Site access. However, the first time a User ever connects with a data set not already prepared by the nightly Grouped Push process the server will start preparing this data for them. This can take some time. However, once this process completes it should be quick for subsequent users.

The Grouped Push process is documented here Synchronization Rules (ifs.com)

Cheers

James

Hi,

Indeed, there is a problem with Grouped Push. I’ve found almost 200 000 rows in mobile_transaction_offline_tab and seems like there is a problem with processing them due to ORA-00001 error in MOBILE_TRANSACTION_PUBLISH_SYS

The procedure has been recently changed in standard, so we are going to apply the change (only in the procedure below as the change was marked as grouped patch to apply with a whole UPD)

PROCEDURE Insert_Offline_Rows___ (
   entity_                IN Transaction_Entity_Row,
   transaction_filter_id_ IN VARCHAR2,
   objkeys_               IN Objkey_Table,
   context_               IN Transaction_Context) 
IS
   tab_ Mobile_Objkeys_Type;  -- Local PLSQL collections cannot bind into insert, update, delete, or merge
   insert_count_ NUMBER;
BEGIN
   IF objkeys_.COUNT > 0 THEN
      SELECT column_value
        BULK COLLECT INTO tab_
        FROM TABLE(objkeys_);
      
      --Only insert missing OBJKEYs to the table
      INSERT INTO mobile_transaction_offline_tab(app_name, app_version, entity, transaction_filter_id, objkey, rowversion)
      SELECT entity_.app_name, entity_.app_version, entity_.entity, transaction_filter_id_, D.column_value, 1 FROM TABLE(tab_) D
       WHERE NOT EXISTS (
        SELECT 1 FROM mobile_transaction_offline_tab
         WHERE app_name    = entity_.app_name
           AND app_version = entity_.app_version
           AND entity      = entity_.entity
           AND transaction_filter_id = transaction_filter_id_
           AND objkey = column_value);

High number of record in mobile_transaction_offline_tab causes slowness each time grouped push is being executed..I expect that after the fix the initialization time will be shorter.

@James Ashmore  - from your experience - is the default 10 seconds execution interval of Grouped Push in database processes proper, or should it be increased? I think it’s a default setting, not changed by anyone.

Yes, the 10 second execution interval should be fine - we have conducted lots of testing around this area to ensure the parameters are satisfactory for all installations. Please retest once the update has been applied

Cheers

James

Hi @HubertZ Thanks for sharing the investigation results with reference to MWO initialization. Would you kindly advise if the above inserted procedure worked with reducing the time, as we are facing similar longer waiting times during the device initialization. We are using Application 10 UPD 9. Thanks for your kind thoughts.

Hi, I’m facing the same.

Any news @HubertZ ?

Tks a lot

Hi @lopespetro & @ISD 

The fragment of the patch mentioned above resolved the ORA-00001error, but the synchronization time remained long. I’ll have to look into again as we have now few users facing this issue.

Best regards,

Hubert

Hi @HubertZ Thanks for your kind feedback. Would be great if you could kindly share any findings and recommendations on further investigations. Good luck. Thanks. 🙂

Hi,

I’m wondering if the information from lobby could let me find what’s causing the initialization time.

Or if the running background jobs affect the initialization time.

The time in seconds in first column varies, the longest at nigth.

But when I take a new device and login to mWO and start initialization, does it have to wait for a particular process in server to finish?

I did a test yesterday, connected to TEST environment and start initialization. It was running quickly first, but next for a good 20-30 minutes it seemed like it was waiting for the server.

@James Ashmore  - you probably know the most how does it work - could you please add a coment? 

Customer has reported me 2-3 users who were unable to initialize in 2 hours. They got new tablets and were unable to work. 

That’s how it looked yesterday on TEST - a long break between 13:07:09 and 13:41:07

For some entities there are filters using contract (one user = one contract/site) but people using mWO replace each other, so I can’t see other way to limit number of data.

Best regards,

Hubert

The delay in the sync looks like it is down to Grouped Push.

Grouped Push collects data for known user filters based on the users already initialized. If the filter changes then the Grouped Push process will start the collection of data for the user on Initialization. If its a large dataset then this will take time.

This is why we often see the first Initialization takes time yet subsequent initializations are faster.

At the moment the Lobby doesn’t display Grouped Push statistics but we are working on this.

Cheers

James