Closed Bug 553709 Opened 13 years ago Closed 12 years ago

Syncing "Browsing History" uses 100% of a CPU core for extended periods

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bugzilla, Assigned: Mardak)

References

Details

(Keywords: hang)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090615 Firefox/3.5
Build Identifier: 1.1

When Weave reports in the status bar that it is synchronising my Browsing History, one CPU core will stick at 100% until it has completed this task. This often takes 2-3 minutes due to the very large amount of Browsing History which my Weave instance has to handle.

Reproducible: Always

Steps to Reproduce:
1. Execute a very large amount of browsing on one Weave-enabled browser.
2. Start a sync on a different computer to bring the history to it
Actual Results:  
One CPU core can be observed stuck to 100% while "Weave is syncing Browsing History" is present in the status bar. 

This will often will cause "Window not responding" errors from Windows 7.

Expected Results:  
Weave would be expected to apply the synchronised browsing history at a reasonable rate so as to not interrupt the browsing experience.

An attachment will be created containing the verbose log of an example of one of these problem synchronisations.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-weave1.3+
OS: Windows 7 → All
Hardware: x86 → All
Target Milestone: --- → 1.3
Assignee: nobody → edilee
Keywords: hang
Looking at the logs, it seems like it's hanging/busy for 20 seconds at a time each time it fetches a group of 150 history items.

For each item, it needs to reconcile and potentially create the item if it doesn't exist. Some reason I remember posting stats of putting dummy logic for _isEqual and reconcile and how much it sped up things, but I can't find it right now...

But basically, it seems like isEqual does 1 query and reconcile can do 2, and there's a base overhead of initiating a sqlite query even during a transaction, so these overhead costs add up.
Whiteboard: [b2]
Whiteboard: [b2]
Target Milestone: 1.3 → 1.3b3
Attached patch v1Splinter Review
Attachment #442510 - Flags: review?(mconnor)
Attachment #442510 - Flags: review?(mconnor) → review+
http://hg.mozilla.org/labs/weave/rev/7cff747c3fa7
Sync asyncExecute to avoid forcing synchronous waits on disk but keep existing calling conventions (no callbacks) for callers by using Sync.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
http://hg.mozilla.org/labs/weave/rev/759a7065ae20
Bustage fix from sync-asyncExecute: don't throw as the old code would catch and implicit return undefined.
Blocks: 562379, 562378
Component: Firefox Sync: Backend → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.