******
Ok - here's the scoop after being on-site and testing out a full lab (35
thin-clients) launching Firefox, with no current ~/.mozilla profile (I nuked
them all before testing), with and withOUT pref("toolkit.storage.synchronous",
0); set in /etc/firefox/pref/firefox.js (which will affect ALL users):
----------------------------------------------------------
'toolkit.storage.synchronous' pref NOT set): Running Firefox on local LTSP
server with no profile with the following command:
Rendered 99 counts of fsync.
---
'toolkit.storage.synchronous' pref SET): Running Firefox on local LTSP server
with no profile with the following command:
Rendered 28 counts of fsync.
---
'toolkit.storage.synchronous' pref NOT set): Running Firefox on local LTSP
server with existing profile (from above) with the following command:
And then opening up tabs for slashdot.org, yahoo.com and google.com:
Rendered 48 counts of fsync.
---
'toolkit.storage.synchronous' pref SET): Running Firefox on local LTSP server
with existing profile (from above) with the following command:
And then opening up tabs for slashdot.org, yahoo.com and google.com:
Rendered 24 counts of fsync.
----------------------------------------------------------
Ok. So now we have sort of a baseline of how the toolkit pref works for
fsyncing. Now what I did was simulated a full class of students coming in,
logging into Gnome, and, all at the same time, launching Firefox.
Instances of launching a full lab of thin-client firefox sessions, with NO
profile, were pretty different when 'toolkit.storage.synchronous' was set as
opposed to not. Without it set, we waited for about 15 minutes, and only about
1/2 of the thin-clients had launched Firefox. WITH it set, again, with new
profiles (I nuke them every time), it took about 5 minutes for all systems to
launch Firefox. Better, but still really really bad.
I used the following command on 3 different thin-clients to guage where firefox
was hanging. I saw a commonality through all of them - it would hang at this
point in the strace:
RIGHT at the "read(15, " it would hang for 3-8 minutes before it proceeded
through and load Firefox. "15" was also "19" and "23" - not sure if this
matters. Sometimes it would proceed through and load the UI, sometimes it would
process a bunch more strace info and then hang on another "read(19, " line.
AND, it wasn't always right after the "nsWebHandlerApp.js" line - a couple of
other times it was here:
---
open ("/dev/random", 0_RDONLY) = 19
(read (19,
---
And it would hang.
AFTER launching the UI (finally), I saw (which might be completely normal) a
continuous cycle of the following in strace:
---
gettimeofday({1221521746, 829628}, NULL) = 0
read(3, 0x8075324, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12,
events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=14,
events=POLLIN}], 7, 0) = 0
---
It would hang at "poll( "and cycle through these messages.
I just updated the Bugzilla Bug 453704 ( https:/ /bugzilla. mozilla. org/show_ bug.cgi? id=453704 ) with new information I gathered while troubleshooting one of my problem labs this afternoon. Here is the text I posted there:
****** storage. synchronous" , pref/firefox. js (which will affect ALL users):
Ok - here's the scoop after being on-site and testing out a full lab (35
thin-clients) launching Firefox, with no current ~/.mozilla profile (I nuked
them all before testing), with and withOUT pref("toolkit.
0); set in /etc/firefox/
------- ------- ------- ------- ------- ------- ------- ------- -- storage. synchronous' pref NOT set): Running Firefox on local LTSP
'toolkit.
server with no profile with the following command:
strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l
Rendered 99 counts of fsync. storage. synchronous' pref SET): Running Firefox on local LTSP server
---
'toolkit.
with no profile with the following command:
strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l
Rendered 28 counts of fsync. storage. synchronous' pref NOT set): Running Firefox on local LTSP
---
'toolkit.
server with existing profile (from above) with the following command:
strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l
And then opening up tabs for slashdot.org, yahoo.com and google.com:
Rendered 48 counts of fsync. storage. synchronous' pref SET): Running Firefox on local LTSP server
---
'toolkit.
with existing profile (from above) with the following command:
strace -f -e fsync firefox 2>&1 | fgrep fsync | wc -l
And then opening up tabs for slashdot.org, yahoo.com and google.com:
Rendered 24 counts of fsync. ------- ------- ------- ------- ------- ------- ------- --
-------
Ok. So now we have sort of a baseline of how the toolkit pref works for
fsyncing. Now what I did was simulated a full class of students coming in,
logging into Gnome, and, all at the same time, launching Firefox.
Instances of launching a full lab of thin-client firefox sessions, with NO storage. synchronous' was set as
profile, were pretty different when 'toolkit.
opposed to not. Without it set, we waited for about 15 minutes, and only about
1/2 of the thin-clients had launched Firefox. WITH it set, again, with new
profiles (I nuke them every time), it took about 5 minutes for all systems to
launch Firefox. Better, but still really really bad.
I used the following command on 3 different thin-clients to guage where firefox
was hanging. I saw a commonality through all of them - it would hang at this
point in the strace:
--- "/usr/lib/ xulrunner- 1.9.0.1/ components/ nsWebHandlerApp .js", S_IFREG| 0644, st_size=6920, ...}) = 0
stat64(
{st_mode=
open("/dev/random", O_RDONLY) = 15
read(15,
---
RIGHT at the "read(15, " it would hang for 3-8 minutes before it proceeded p.js" line - a couple of
through and load Firefox. "15" was also "19" and "23" - not sure if this
matters. Sometimes it would proceed through and load the UI, sometimes it would
process a bunch more strace info and then hang on another "read(19, " line.
AND, it wasn't always right after the "nsWebHandlerAp
other times it was here:
---
open ("/dev/random", 0_RDONLY) = 19
(read (19,
---
And it would hang.
AFTER launching the UI (finally), I saw (which might be completely normal) a
continuous cycle of the following in strace:
--- {1221521746, 829628}, NULL) = 0 POLLIN| POLLPRI} , {fd=11, events= POLLIN| POLLPRI} , {fd=12, POLLIN| POLLPRI} , {fd=13, events= POLLIN| POLLPRI} , {fd=14,
gettimeofday(
read(3, 0x8075324, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8,
events=
events=
events=POLLIN}], 7, 0) = 0
---
It would hang at "poll( "and cycle through these messages.
You can find the 3 different workstations' strace logs, with and without the logicalnetworki ng.net/ other/ac/
toolkit pref enabled, here: http://
I really hope this information helps. After seeing this happen with my own two
eyes, I have to say...wow.