134252 - MacOSX pageload times risen by 125ms since 3/23

Status: RESOLVED WORKSFORME

(Core Graveyard :: Tracking, defect)

Description

[Mike Pinkerton (not reading bugmail)]

check the pageload times on 
ftp://ftp.mozilla.org/pub/data/loadtimes/daily_loadtime.html

macOSX spiked hard after 3/23's build. this is pretty critical.

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Who runs these tests?  Has there been any configuration change in the build
machine?  Has anyone else reproduced this increase using nightly builds? 
Between which builds did it happen?

Comment 2

[tor]

Could this be caused by the backout of bug 123899?

Comment 3

[Bill Law]

The uptick seems to match the decrease we saw on 3/20 (when bug 123899 was 
fixed).  MacOSX jumped back up a little more than the other platforms when that 
fix was backed out, but it isn't clear that that platform didn't see a bigger 
decrease when that bug was fixed.

Mike, can you determine whether there's something really amiss on MacOSX.  I'm 
not sure we can hold the tree closed based on what we've got so far.

Note that we're currently still blocked by more recent regressions as noted in 
bug 134137.

Comment 4

[Mike Pinkerton (not reading bugmail)]

bill, i disagree.

all platforms dropped sharply about the time 123899 landed, but when it was
backed out, mac jumped sharply and the other platforms didn't respond in kind.
that means it's probably not 123899.

as for not holding the tree closed, we have evidence of a major slowdown. that
falls under the new m.o perf regression rules. the tree stays closed until we
know why. period.

Comment 5

[John Morrison]

Other testing on "low end" machines doesn't show a problem.
  http://www.mozilla.org/quality/perf/pageload/pageload-results.html
As law notes, there should be some rise in the numbers of 3/26, since we 
started to load content that, for a while, we were failing to load (a false
speedup).

But I really have to apologize, as I have not been paying as much attention to 
these results as I used to do. twalker and I will go over the recent numbers 
for these tests and reconfirm some values and then update here. But given 
the other results, I wouldn't hold the tree for this bug.

Comment 6

[Bill Law]

I thought maybe MacOSX dropped more sharply, too, but maybe I'm being too 
optimistic.  If we look at where we're at relative to the 3/16 line on that 
chart, then it seems that all platforms are pretty much at the same spot 
relative to that point (slightly lower).  MacOSX perhaps not quite as much 
lower.

I can't make any sense of jrgm's chart.

Comment 7

[Cathleen]

we need more time to look at datas, jrgm and tracy are going to evaluate.

peterv's checkin on 3/19 made 20ms improvment on btek (1200s downto 1980s), but
he backed out the change on 3/25 due to regressions.  I think the number
represent the effect of peterv's backout.

down grading to crtitical till we find more info.

Comment 8

[Mike Pinkerton (not reading bugmail)]

is anyone looking at this? what's the status?

Comment 9

[Cathleen]

no status on this yet, as far as i know.

Comment 10

[saari (gone)]

topembed- since this isn't blocking an embedding customer, but it really does
need to get fixed, so it gets marked embed. I've also marked it nsbeta1+ [adt2].
Probably should be [adt2 RTM] realistically

Comment 11

[Paul Wyskoczka]

Added nsbeta1+ and [adt2 rtm] per saari's comments

Comment 12

[Frankie]

It's 9 months later. Is this bug still relevant?

Looking at the 1 year loadtime graph, the 125ms jitter in March looks like a
random aberration. And it's completely overwhelmed by the 900ms drop in early
November.

Comment 13

[Simon Fraser [no longer active]]

Works for me.