785899 - Significant freezes during operation, when Firefox sync is enabled

Status: RESOLVED INACTIVE

(Firefox for Android Graveyard :: Android Sync, defect, P3)

Description

[Michail Pappas]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

When using Firefox 14.0.1 on a Samsung Galaxy S running Android 2.3.7, I have completely different behaviour, depending on whether I enable sync or not. If Firefox sync is at play, browser freezes to the point of even having to restart the phone.

Specifically, I am using Firefox 1-2 times per weekon the mobile. Most work on Firefox is on my 3 work computers, which were firefox sync'ed whereas the mobile version was not at all. Then I decided to add the mobile. Sync was made, the bookmarks, history etc appeared on the mobile firefox. BUT I am now experiencing significant freezes and CPU spikes on the Galaxy S.



Actual results:

Like I said, after enabling FF sync, it is impossible to operate the device, due to intermittent freezes and hangs.

Please note that this behaviour reminded me of the issues I have been experiencing on my desktop platform, in bug# 686025. For that purpose, I tried to find a places-maintenance extension for the mobile firefox, but it was not compatible with mobile FF 14.0.1

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Well, I have been unable to repo this (and thus never filed my own bug), I have experienced similar behavior in the past. I did some development which required me to constantly add and remove sync. Both my devices seemed to be running slower when sync was enabled (i.e. animations were not smooth, my TF201 constantly hanged). A short time after I finished testing, things got back to normal without me having to remove sync – I figured this performance decrease was related to the background downloading of data. I noticed I only had the problems when the Firefox sync process was actively running (by looking at the task manager).

Looking through logcat, I saw nothing peculiar about it besides the fact that I had a large number of devices (30? 40?) on my account, but seeing how Michail also has issues, I imagine this is unrelated.

Comment 2

[Nick Alexander :nalexander [he/him]]

A large number of devices on your account is just the fallout from re-installing a number of times: you get a new client ID each install.  The server only purges them after 3 weeks of inactivity, and it's quite difficult to delete them on Android account removal (but see Bug 770785 for tracking).

I don't think these extraneous records will slow things down.  A TF201 has a crazy slow disk.  Did you have a lot of activity (bookmarks, history items, etc) on each sync?  What was your network like?

Comment 3

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Nick Alexander :nalexander from comment #2)
> Did you have a lot of activity (bookmarks, history items,
> etc) on each sync?

Since I was re-adding accounts and I synced pretty much everything, I assume it was syncing everything each time. I have around 17MB of data, according to the quota screen on desktop.

> What was your network like?

MTV office WiFi, which is pretty mediocre on my devices. The TF201 has especially bad WiFi connectivity too.

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Michael Comella (:mcomella) from comment #3)
> (In reply to Nick Alexander :nalexander from comment #2)
> > Did you have a lot of activity (bookmarks, history items,
> > etc) on each sync?
> 
> Since I was re-adding accounts and I synced pretty much everything, I assume
> it was syncing everything each time. I have around 17MB of data, according
> to the quota screen on desktop.

No two ways about it, first sync is going to slow things down, seeing as it has 17MB to pull down and write to disk.  We're definitely interested in improving first sync (see, for example, Bug 730142) but it's not a priority.

> > What was your network like?
> 
> MTV office WiFi, which is pretty mediocre on my devices. The TF201 has
> especially bad WiFi connectivity too.

Indeed it does.  The TF201's disk is actually a series of hamsters that run in circles to maintain each bit's state; I'm not surprised you're seeing bad perf with this write volume.  If it persists beyond first sync + fallout from the fisrt sync, we might have more investigation to do.

Comment 5

[Michail Pappas]

You're making me feel a bit pessimistic on this :) If this issue arises on a tablet class system, then which would be the chances of resolving this for single-core mobiles?

My own environment is 4 sync machines (incl. the mobile), whereas the heavy use is made between on the two of them. The mobile is utilized like I said quite seldomly. Connection and sync is only made via Wifi and not constantly via 3G. (Off-topic a bit: once a wifi connection is made at home with a perfect signal, it takes a LOT of time, even more than 15 minutes, for the sync indicator to disappear). 

Finally, this was not the initial sync. I had already sync'ed FF some weeks ago on the mobile. Do I understand correctly in that if FF remains un-utilized, the specific machine account contents on sync get purged? This would mean that each sync is essentially a full sync for me then?

Comment 6

[Michail Pappas]

(In reply to Michael Comella (:mcomella) from comment #1)
> I noticed I only
> had the problems when the Firefox sync process was actively running (by
> looking at the task manager).

Sorry Michael, failed to read this. I observe the same behaviour. That is, freezing mostly takes place during sync (from the circular arrows icon). After that, performance does seem a lot snappier. Stil not as fast as when a clean firefox is operating though...

Comment 7

[Michail Pappas]

Some updates:

* Issue persists after updating to 15.0
* Behaviour seems similar to the one witnessed in bug# 713282: sync takes ages to complete (> 5'). This does not happen only on the initial sync, but rather on subsequent syncs as well.

I must stress that I do not have a 3G connection (hence, updates due to my frequent surfing activities on my desktop rigs are larger in  size).

Comment 8

[Richard Newman [:rnewman]]

If I had to guess, your first sync is never successfully completing, so each subsequent sync has lots of work to do. 

A log will confirm:

http://160.twinql.com/how-to-file-a-good-android-sync-bug

Comment 9

[Michail Pappas]

(In reply to Richard Newman [:rnewman] from comment #8)
> If I had to guess, your first sync is never successfully completing, so each
> subsequent sync has lots of work to do. 

Not sure here. I *think* it might have completed at some point. However, if using the mobile seldomly means that each time ff is started a full sync process will take place, then it means that I ff will always be freezing/slow to the point of being unusable. Or doesn't it work that way?
 
> A log will confirm:
> 
> http://160.twinql.com/how-to-file-a-good-android-sync-bug

I can try producing a log here. One question though: do you feel that working with ff sync on a single-core Android mobile is possible or not? That is, am I perhaps trying to attain the impossible here?

Comment 10

[Richard Newman [:rnewman]]

(In reply to Michail Pappas from comment #9)

> Not sure here. I *think* it might have completed at some point. However, if
> using the mobile seldomly means that each time ff is started a full sync
> process will take place, then it means that I ff will always be
> freezing/slow to the point of being unusable. Or doesn't it work that way?

It doesn't work quite that way.

Once the big first sync is done, only new records will be retrieved.

If it has to pull down a lot of records (e.g., if you sync once a month, and you browse hundreds of new sites on your other machines in the mean time), then your device will be doing more work than if it syncs every few hours. It'll pull down lots of history, the usual tab blob, client blobs, and some new bookmarks.

The longer you leave it between syncs, the more work it'll do, which will eventually converge on a full sync.

If every sync takes the same amount of time, then my hypothesis is that one of the engines is failing part-way through, and it's repeating some work each time.


> I can try producing a log here.

Please do.

If you have Android developer tools installed, dumping the output of `adb logcat -v time` into a file, then starting a sync from the account settings, will be the most useful debugging tool.

If you don't, then whatever you can grab from CatLog or ALogCat will be useful.


> One question though: do you feel that
> working with ff sync on a single-core Android mobile is possible or not?

Yes, but depending on memory and which CPU.

My last phone was an old single-core HTC EVO (1GHz Snapdragon, 512MB RAM) and Sync worked OK -- there were way worse offenders for slowdown and memory usage. Android as a whole is just about usable on this class of device.

An ARMv6 device with constrained memory is going to be painful, so I wouldn't recommend that -- but then, Android 2.x on ARMv6 + 256MB is barely able to run a browser at all.

On my dual-core Galaxy S3, I can't even tell that Sync is working.

Comment 11

[:Grisha Kruglov]

Not closing this since some of the same fundamental problems apply years later (large first sync still needs to do a lot of work), even though things have gotten better.

Comment 12

[Firefox Bug Husbandry Bot]

Closing per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Contact :susheel if you think this bug should be re-opened