Pick medianRun instead of fastestRun until SPDY issues are fixed
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Peter
	Mar 17 2016, 9:48 AM

Description

It happens that we get an unrealistic fast TTFB in our tests in our tests because of problem with SPDY in WebPageTest. It happens in first run and second page view but I think they are unrelated.

We should verify that we get wrong TTFB for our first runs (it could have been fixed in Chrome 49, WPT uses the timing event log and there's been a fix there).
If we still have the problem we should choose to pick the median run instead for a while, because the bug doesn't always happens so it is a bigger chance we get correct values if we pick the median run.

Related Objects

Mentioned Here: T130182: TTFB is sometimes unrealistic fast for first view using Chrome
T135482: Start render catching browser loading bar for mobile

Event Timeline

Peter created this task.Mar 17 2016, 9:48 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 17 2016, 9:48 AM

• Gilles moved this task from Inbox, needs triage to To-do: Goals prioritized current Quarter on the Performance-Team board.Mar 17 2016, 8:39 PM

Krinkle triaged this task as Medium priority.Mar 31 2016, 3:08 AM

We still have the problem after updating to Chrome 49 but lets wait a while before we change, seems like H2 is coming soon.

We still use medianrun=fastest at the moment. The SPDY issue was resolved agaik, but there may be other reasons for moving to the median:

Related issues:

However it'd be nice to stick to fastest as that is most effective at reducing noise.

Yep you are right SPDY issues and other problems seems to be fixed now. Lets continue use the fastest one.

Pick medianRun instead of fastestRun until SPDY issues are fixedClosed, ResolvedPublicActions

Description

Related Objects

Event Timeline

Pick medianRun instead of fastestRun until SPDY issues are fixed
Closed, ResolvedPublic
Actions