poor performance in 1.8/1.1a1 nightlies
Felix Miata
I keep SM open 97% of the time I'm not unzipping a new nightly, one each
of browser, mail, & CZ windows, with occasional use of Domi and WebDev.
Uptime ranges from several hours to several days, but not infrequently
goes 2-3 days. My history is set to 150 days and is currently 5836k. My
bookmarks are 449k. RAM consumed by SM is typically around 200M.
I have a set order I use most of the time to open the browser with
frequently used pages. I open 5 local pages from the urlbar history and
one bookmark in the first tab. I open 4 local pages from the urlbar
history in the 2nd tab. In tab 3 I open
http://www.mozilla.org/ports/os2/, page down twice, open "Recently
Changed Warpzilla Bugs" in a tab 4, and "Current Open Warpzilla Bugs" in
the current tab 3. I goto tab 4, goto bookmarks, and open a query of all
TE bugs created in past 3 days. I then open
https://bugzilla.mozilla.org/ from bookmarks, click on "bugs filed
today, and switch to tab 3. In tab 3 I open a saved search from
bookmarks of all bugs I ever filed, then switch back to tab 4 and open a
saved search of various non-FF and non-TB bugs in past 1d. When it
finishes loading, I edit it to either 2d or 3d, then go back to tab 3
and load from bookmarks my saved search of all bugs I'm CC on.
That last big query (#594 currently: http://tinyurl.com/msj4y) is the
one where the problem is pronounced, though it may be evident in the
"all my bugs" query or any of the today queries. It is NOT reproducible
at will. Normally the all CC query paints "Please stand by ..." after no
more than 11 seconds, and reaches "done" within 30 seconds or so.
IIRC, some time after the 13 April build, the last before a long OS/2
build break that resulted on no nightlies began, and after the fix for
https://bugzilla.mozilla.org/show_bug.cgi?id=335142 I noticed it can
take very long, pegging the CPU the whole time. IOW, before the 13 April
build, I don't remember ever seeing this. That query normally does peg
the CPU, but for only ~30 sec, which seems tolerable. The first
post-335142 fix build was 25 April.
Today I timed it occurring twice in yesterday's build. Stats:
Please stand by Complete
Normal ~10sec ~30sec
#1 102sec 129sec
#2 135sec 163sec
Those were the only two repeats of the behavior today on trying each of
13th and 25th-30th builds no less than once, and several more than once.
Both times it manifested and I timed it that query was the first and
only URI opened immediately after browser open, which each time came
immediately after unzipping fresh the build. At the time of timing, no
other browsers were open, and no foreground tasks of any kind were
active. System is 2.8G P4 w/ 512M DDR2 on eCS 1.14 with ft2lib 2.6b.
--
"All have sinned & fall short of the glory of God." Romans 3:23 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.no-ip.com/
Dave Yeo
click on the desktop to take focus away from Seamonkey.
Here (using a trunk from the 11th) with Seamonkey in the background the
please standby lasts about a minute and the page is done at about 3
minutes. CPU sits at about 25% except a brief peak when the please
standby ends and another brief peak (less then a second) at the end. The
whole time my tiny pipe is full so it actually takes about 3 minutes to
DL the page. (26.4k dialup).
Put Seamonkey in the foreground and after about 3 minutes CPU peaks for
an additional 2 minutes, 0 bytes are transferred then the page is done.
Very strange but I repeated the test about 6 times and it was pretty
consistent with a bit of variation most likely caused by DL speed. CPU
is a 800Mhz Duron 256 MB ram, seamonkey has been open a couple of days
(swap is at 100 MB) with currently 10 tabs open. Your page in a separate
window launched from PMMail.
Dave
ps just tested again while writing this in Compose (seamonkey), didn't
time but lots of periods with 0 bytes transfered and very low CPU usage
(perhaps 0-20% with quite a bit 0%) and must of taken 3 minutes for the
please standby window to end. Still very sporadic DL speed and next to
no CPU usage and it is looking like perhaps 10 minutes to load. Writing
this message is blocking your page and now not sure if it will finish <gr>
Felix Miata
find some existing bugs. It was truly painful having to wait 2+ minutes
to finish a query or even just load a bug page so many times. Back on
2006041309 I've had a total of 0 Bugzilla events take more than about 30
seconds to complete, even when doing a query while loading several bugs
from another query. It seems what this problem may be is an https
problem that manifests when loading pages full of form elements and/or
large tables. I've not noticed trouble on bank sites, but I suspect
they're smaller or don't have so many forms or tables. The long event
times are similar on Bugzillas from freedesktop, redhat, novell and
mandriva.
Ralph Haase
> As these are all SSL sites could this be a regression by Kai Engert's
> Crypto/PSM patches that he posted about a few weeks? At the moment I
> find a post in mozilla.dev.planning pointing to bug 235773.
I think, i have the same problem. Have you seen this?
MID: <4bgpu7F...@individual.net>
R.Haase
--
Answers in Newsgroups only to: Ralph_Haase @ Web.de (without blanks).
Mails to the FROM- Address become not read.
Felix Miata
> I think, i have the same problem. Have you seen this?
> MID: <4bgpu7F...@individual.net>
This what? I click that link, and email opens a compose window.
Ralph Haase
>> I think, i have the same problem. Have you seen this?
>> MID: <4bgpu7F...@individual.net>
^^^^
> This what? I click that link, and email opens a compose window.
I thought, MID is a well-known acronyme...
But this Thread is in german:
http://groups.google.com/group/de.comm.software.mozilla.nightly-builds/msg/ea18c8a4bea8222b?rnum=1
and for a MID (Message IDentifier):
http://messageidfinder.mozdev.org/
Felix Miata
http://groups.google.com/group/de.comm.software.mozilla.nightly-builds/msg/ea18c8a4bea8222b?rnum=1
NAICT from Babelfish's translation, that's some kind of mailnews problem
that has nothing to do with HTTPS web pages pegging the CPU.
Ralph Haase
> NAICT from Babelfish's translation, that's some kind of mailnews
> problem that has nothing to do with HTTPS web pages pegging the CPU.
"My problem" has primary to do with a Mailaccount (pop3 with SSL)
and with the web.de-login (https).
See in the thread in de.comm.software.mozilla.nightly-builds:
MID: <4bovqdF...@individual.net> (with online-translation):
======
Which was noticeable to me thereby also, that logging and representing
the sides in with e.g. Web.de lasts also for a very long time. Whether
it has to perhaps do with SSL or general working with name/password?
======
Is this also the "last good" SM for you?
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20060413 SeaMonkey/1.1a
All newer Builds, which I tested, has the same problem.
Felix Miata
> "My problem" has primary to do with a Mailaccount (pop3 with SSL)
> and with the web.de-login (https).
> See in the thread in de.comm.software.mozilla.nightly-builds:
> MID: <4bovqdF...@individual.net> (with online-translation):
> ======
> Which was noticeable to me thereby also, that logging and representing
> the sides in with e.g. Web.de lasts also for a very long time. Whether
> it has to perhaps do with SSL or general working with name/password?
> ======
> Is this also the "last good" SM for you?
> Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20060413 SeaMonkey/1.1a
> All newer Builds, which I tested, has the same problem.
Based upon your confirmation I've filed a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=336944
Felix Miata
> Is this also the "last good" SM for you?
> Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8) Gecko/20060413 SeaMonkey/1.1a
> All newer Builds, which I tested, has the same problem.
Ralph, are you still using the 0413 build? In about:config, what is your
setting for browser.sessionhistory.max_total_viewers ? I'm using the
0520 1.8 nightly, so far, with no apparent trouble like before.
Ralph Haase
> Ralph, are you still using the 0413 build?
Yes. All newer builds that i tested, are too slow...
> In about:config, what is your setting for
> browser.sessionhistory.max_total_viewers ?
The value is: -1
> I'm using the 0520 1.8 nightly, so far, with no apparent trouble
> like before.
...that looks good.
Before i forgot it:
https://bugzilla.mozilla.org/show_bug.cgi?id=336944
With or without OCSP makes with me also no difference.
Ralph Haase
> Ralph, are you still using the 0413 build? In about:config, what is
> your setting for browser.sessionhistory.max_total_viewers ?
I have changed the value to: 0 and now i can use the newer builds.
Where did you find this pref (btw. the solution for the problem)?
When i read this:
http://www.mozilla.org/security/announce/2006/mfsa2006-29.html
i am not sure, what i am thinking about this pref.
> I'm using the 0520 1.8 nightly, so far, with no apparent trouble like
> before.
The Build (20060522 SeaMonkey/1.1a ) works also fine (and very fast).
Felix Miata
> Felix Miata wrote:
>> Ralph, are you still using the 0413 build? In about:config, what is
>> your setting for browser.sessionhistory.max_total_viewers ?
> I have changed the value to: 0 and now i can use the newer builds.
> Where did you find this pref (btw. the solution for the problem)?
It's the bfcache, designed to speed up reaction to the forward & back
buttons.
>> I'm using the 0520 1.8 nightly, so far, with no apparent trouble like
> > before.
> The Build (20060522 SeaMonkey/1.1a ) works also fine (and very fast).
I changed mine from 0 to 3 at the same time I unzipped a newer build,
and haven't gone back to see whether the setting or the build made the
apparent difference. I still see occasional delays using https pages
like bugzilla and gmail that I don't see using 1.0.2. I've been
alternating between 1.0.2 & 1.1a nightlies just to try to understand the
difference in behavior better.