Closed Bug 409742 Opened 17 years ago Closed 16 years ago

Firefox becomes unresponsive (uses 100% cpu) as Weave attempts to synch

Categories

(Cloud Services :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: abillings, Assigned: hello)

References

Details

Weave seems to automatically attempt to synch itself to the server every 30 minutes (at around 22 and 52 after for me). When it does so, Firefox becomes unresponsive for approximately two minutes. On my Mac, I get the "beachball" whenever I move the mouse over the Firefox window and any streaming audio, video or downloads pauses for the duration of the synch.

This was found on Leopard running nightly builds from Trunk. 

I would suggest letting users set the synch period manually. I have no control over how often this occurs and it is very frustrating to be in the middle of a blog post or listening to a podcast and to have everything just stop for a couple of minutes as the synch starts up.
Add my vote to "User-configurable" synching.
IMO, we need to:

a) make it so syncing is done in the background and not block the UI.  This makes it take longer (because we spend cycles going back to the UI thread), but it means Firefox remains reasonably responsive (though likely slower overall).

b) Use the idle timer to delay syncing until the user is away for a little while.

c) Sync less frequently when we know the user hasn't changed anything locally.  We can't avoid it altogether because there can be changes from the server, though.

After (a), (b), and (c), I think we can look at what kind of knobs we can give power users so they can tweak the behavior to their liking.

I just released an update to Weave (0.1.12.11) which does part of (a) by doing encryption and decryption asynchronously.  It would be useful if you could pinpoint exactly where in the logs it seems to be beachballing for you, so that I can try to make it as smooth as possible (though again keep in mind that some slowness is almost unavoidable).
Assignee: nobody → thunder
Status: NEW → ASSIGNED
I'll see if I can nail it down but I am assuming it is during encryption because the UI for updating (and uploading) occurs a minute or three after I get Mr. Beachball and the UI is briefly responsive before going to heck again (with the whirling knob for weave spinning). When it first hangs, I have no visual indicator from Weave that it is doing anything yet.
Okay, make sure to update and give 0.1.12.11 a try.  It should not beachball during encryption anymore.

It can still beachball on first sync or if you have a ton of changes, that's still on my list of things to fix.

Thanks!
Updating to 0.1.12.11 fixed this for me. I force a sync, CPU did not peg and no "unresponsive script" alert messages.
Yay! :-)
Looks like some folks are still seeing this problem during encryption/decryption; see bug 410488 for more details.
I'm seeing this behavior too. Here's my setup:
* Windows XP Professional Build 2600.xpsp_sp2_gdr.070227-2254 (Service Pack 2)
* Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010405 Minefield/3.0b3pre
* Weave 0.1.13

Whenever Weave kicks in (the spinning icon at the bottom of the browser), CPU utilization by the Firefox process shoots up to 100% and often Firefox becomes unresponsive. When Weave completes its work (as evinced by the spinning stopping), then everything's hunky-dory again.

I have been noticing this over multiple Minefield builds (and as far as I can remember ever since I started using Weave). My other addons are: Adblock Plus, Customize Google, CuteMenus - Crystal SVG, Greasemonkey (with no user scripts), Live HTTP Headers, Nightly Tester Tools.
Looks like platform property can be cleared for this bug.
Sorry, Dan.  I forgot to list my Add-ons in Bug 410488, forgetting that they could be relevant.

They are:

Adblock Plus 0.7.5.3
CustomizeGoogle 0.68
DOM Inspector 1.9b3pre/1.9b2
Joey 0.3.0.0
Weave 0.1.13 (obviously)
The bug affects me as well.  

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2 ID:2007121120

Adblock Plus 0.7.5.3
ColorfulTabs 2.0.7
CookieSafe 2.0.6
Firebug 1.1.0b10
googlebar 0.9.15.11
Greasemonkey 0.7.20070607.0
IE Tab 1.3.3.20070528
Java Console 5.0.14
MinimizeToTray 0.0.1.2006102615+
Nightly Tester Tools 1.3b4
NoScript 1.2.6
Personas for Firefox 0.9.1
Print/Print Preview 0.5
Tab Mix Plus 0.3.6.0.071228
Weave 0.1.14
Xinha Here! 0.10.0

OS: Windows XP, SP2, all patches as of 1/9/2007.  System: Pentium M, 1.4 GHz, 1.2 GB RAM.  
Summary: Firefox becomes unresponsive every 30 minutes as Weave attempts to synch → Firefox becomes unresponsive (uses 100% cpu) as Weave attempts to synch
It's doing this on every sync for me, not just the first one. Possibly due to the fact that I'm using weave on multiple machines?

Let me know if you want to come by and debug.
Hi guys,

I have also high cpu load on weave sync.

After smal investigation I have descovered high virtual memory load on sync also. It jumps from 160 to 400 Mb (several pages are opened).

I have also descovered high CPU (~96%) and virtual memory (160 -> 220) load then I open "Activity Log...". I have first message in the begining of janyary and the whole log is auite long. Maybe it's so long that it's opening and writing to it produces such high CPU and MEM load?

There can I clean up thi log?
I think the latest developer snapshots should improve performance significantly.  Can you guys reopen this bug (or, preferably, file more specific bugs...) if you're still having performance problems?

Latest snapshot is version 0.1.21, and you can get it here:

https://labs.mozilla.com/forum/index.php/topic,544.0.html
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
This was fixed. I haven't seen this with 0.1.21 or higher.
Status: RESOLVED → VERIFIED
I have similar issue but then syncing Cookies or Passwords or Form Data or everything at once.
Windows XP with FF 3.0 Release
Weave 0.1.30
I have the same thing, syncing everything, on one of my desktops. The other one however is fine, which doesn't make much sense to me because it has less memory than the other.

Info: Vista with Firefox 3.0 using Weave 0.1.30


Component: Weave → General
Product: Mozilla Labs → Weave
Target Milestone: -- → ---
QA Contact: weave → general
You need to log in before you can comment on or make changes to this bug.