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

Page 1 of 1 (10 items)
This post has 9 Replies | 1 Follower

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Posted: Sat, Mar 2 2019 3:13 AM

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:

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

Mark Barnes:

  1. Is it normal for MobileResourceSyncManager to take so long to update?
  2. Should MobileResourceSyncManager still contain data for deleted devices?
  3. 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.

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Mar 2 2019 9:38 AM

Andrew Batishko (Faithlife):
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.

Posts 2080
LogosEmployee

Mark Barnes:
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.

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Mar 2 2019 1:57 PM

Andrew Batishko (Faithlife):
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.

Posts 2080
LogosEmployee

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.

Mark Barnes:
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.

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Mar 4 2019 9:53 AM

Andrew Batishko (Faithlife):

Mark Barnes:
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.

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Mar 16 2019 12:26 PM

Mark Barnes:
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 taghttps://www.dropbox.com/s/ukp9unezdu0ujz7/logos-tagging.mp4?dl=0 

Posts 2080
LogosEmployee

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.

Posts 13359
Forum MVP
Mark Barnes | Forum Activity | Replied: Tue, Mar 19 2019 12:17 PM

Andrew Batishko (Faithlife):

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.

Page 1 of 1 (10 items) | RSS