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

RESOLVED FIXED in 1.3b3

Status

()

RESOLVED FIXED
9 years ago
28 days ago

People

(Reporter: bugzilla, Assigned: Mardak)

Tracking

({hang})

unspecified
1.3b3
Points:
---
Dependency tree / graph
Bug Flags:
blocking-weave1.3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
Created attachment 433645 [details]
Snippet of the Activity Log surrounding the sync concerned

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-weave1.3+
OS: Windows 7 → All
Hardware: x86 → All
Target Milestone: --- → 1.3

Updated

9 years ago
Assignee: nobody → edilee
Keywords: hang
(Assignee)

Comment 2

9 years ago
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.

Updated

9 years ago
Whiteboard: [b2]

Updated

9 years ago
Whiteboard: [b2]
Target Milestone: 1.3 → 1.3b3
(Assignee)

Comment 3

9 years ago
Created attachment 442510 [details] [diff] [review]
v1
Attachment #442510 - Flags: review?(mconnor)

Updated

9 years ago
Attachment #442510 - Flags: review?(mconnor) → review+
(Assignee)

Comment 4

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 5

9 years ago
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.
(Assignee)

Updated

9 years ago
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.