ATTN Bradley or Andrew: Possible performance bug when updating LibraryCatalog?

I took a look at what was happening when the library catalog was updated, and performance seems to have slipped significantly over the last several months. Using ProcessMonitor, I discovered that the majority of the time spent in this operation is actually spent (approximately 105 seconds in my case) reading and writing to MobileResourceSyncManager.

In addition, I discovered that I have no less than 39 DeviceAppIds in my database, dating back to 2012. This is despite only have four devices currently registered to my Logos account, and most of those devices have modified dates from several years ago.

Two of the deviceIDs seem to encompass almost my entire library, and presumably relate to my Windows-based installation.

So, three questions, if I may:

Is it normal for MobileResourceSyncManager to take so long to update?
Should MobileResourceSyncManager still contain data for deleted devices?
Should MobileResourceSyncManager contain data for two Windows installations, when Andrew has said that the library doesn't show other Mac/Windows based devices?

Find more posts tagged with

Comments

Andrew Batishko

Is it normal for MobileResourceSyncManager to take so long to update?

Should MobileResourceSyncManager still contain data for deleted devices?

Should MobileResourceSyncManager contain data for two Windows installations, when Andrew has said that the library doesn't show other Mac/Windows based devices?

1. It takes a lot longer now because we make use of MobileResourceSyncManager to store whether or not you want each of your resources downloaded to the desktop application. It's hard to say whether or not your case is unusual. I don't really have a baseline for comparison.

2. I don't think that the settings for those devices are cleaned up when the device is deleted.

3. Yes. It's going to contain all your devices. Other devices aren't shown in the library mostly because we currently lack a good UI to rename (disambiguate) the installation.

Mark Barnes

https://community.logos.com/discussion/comment/1037209#Comment_1037209

1. It takes a lot longer now because we make use of MobileResourceSyncManager to store whether or not you want each of your resources downloaded to the desktop application. It's hard to say whether or not your case is unusual. I don't really have a baseline for comparison.

Thanks for the reply, Andrew.

It seems like all the resources in MobileResourceSyncManager get updated (rewritten?), even when only one tag is changed. I could understand why you might need to rewrite the data if a resource was added to the library (or to a mobile device), but it seems a very expensive operation for something, like a tag change, that happens fairly frequently.

Andrew Batishko

https://community.logos.com/discussion/comment/1037228#Comment_1037228

It seems like all the resources in MobileResourceSyncManager get updated (rewritten?), even when only one tag is changed. I could understand why you might need to rewrite the data if a resource was added to the library (or to a mobile device), but it seems a very expensive operation for something, like a tag change, that happens fairly frequently.

That sounds strange, and sounds like something that should not be happening. We'll take a look.

Mark Barnes

https://community.logos.com/discussion/comment/1037284#Comment_1037284

That sounds strange, and sounds like something that should not be happening. We'll take a look.

That was something of a guess, based on file activity. I added a single tag to one resource and Process Monitor showed 105 seconds of reading and writing to MobileResourceSyncManager, and then about 45 seconds of reading/writing to the LibraryCatalog.

Andrew Batishko

https://community.logos.com/discussion/comment/1037286#Comment_1037286

As far as I can tell, nothing is writing to that database as a result of changing a tag. However, library catalog indexing (which runs after a tag is changed) will result in calls to retrieve information for each resource, and updating the facet list will requires calls to retrieve information.

Process Monitor showed 105 seconds of reading and writing to MobileResourceSyncManager,

My guess is that these times line up fairly closely with the time it takes to index the library catalog.

Mark Barnes

https://community.logos.com/discussion/comment/1037532#Comment_1037532

Process Monitor showed 105 seconds of reading and writing to MobileResourceSyncManager,

My guess is that these times line up fairly closely with the time it takes to index the library catalog.

I'll take a video of Process Monitor and Logos side-by-side, so you can see what's happening. Calls to MobileResourceSyncManager and catalog.db aren't happening in parallel. Catalog.db happens after MobileResourceSyncManager has finished.

Mark Barnes

https://community.logos.com/discussion/comment/1037540#Comment_1037540

I'll take a video of Process Monitor and Logos side-by-side, so you can see what's happening.

Here's a link to the video. You'll see a huge amount of reading/writing from MobileResourceSyncManager when I delete a tag: https://www.dropbox.com/s/ukp9unezdu0ujz7/logos-tagging.mp4?dl=0

Andrew Batishko

https://community.logos.com/discussion/comment/1040380#Comment_1040380

It's hard to tell for certain, but I didn't see any writing to that file, just reading. I would expect this, since given the yellow bar, it almost certainly rebuilding your library catalog index, and information from that manager is read for each resource. This has been the case since the mobile resource management feature was introduced.

Mark Barnes

https://community.logos.com/discussion/comment/1040384#Comment_1040384

It's hard to tell for certain, but I didn't see any writing to that file, just reading. I would expect this, since given the yellow bar, it almost certainly rebuilding your library catalog index, and information from that manager is read for each resource. This has been the case since the mobile resource management feature was introduced.

Then — especially if you don't clear out unused installations from that file — performance is going to degrade over time, and performance for people who have two or more desktop installations are going to see significantly poorer performance than those with just one installation.