(tl;dr: see https://bugzilla.mozilla.org/show_bug.cgi?id=881804#c103)
Hello all, Shortly after sending this email, I will be landing the patches in https://bugzilla.mozilla.org/show_bug.cgi?id=881804 on mozilla-inbound, and I wanted to give everyone a heads-up on (and justification for) the Tp[45] regression that this landing will cause (assuming it doesn't get backed out for some other reason). The first time these patches landed (before being backed-out for a non-Tp[45] reason), they caused a regression of approximately 6% on Tp*. Further testing on our own private Web Page Test instance ( http://www.webpagetest.org/ - public page, not our private instance) has convinced those of us on the Necko team that the talos regressions are not indicative of performance in the real world for these patches, and thus are acceptable. First, a quick rundown of what these patches do. Given a user's history, necko *may* speculatively issue DNS lookups or begin TCP connections (including SSL/TLS handshake) when loading a page. I say may, because what action we take (if any) is all dependent on how sure we are about the necessity of the action. What this means is that we would expect this code to improve page load time by 1-3 network round trips (100-300ms for my home internet connection, for example), but only when we have enough data to be our most aggressive. The nature of talos is that all tests are run over an effectively ideal network (zero latency, very high bandwidth), so no optimizations we add at the network layer can have any effect on talos *other* than to slow it down (through whatever overhead is added on the page load code path), even on second and subsequent page loads. However, thanks to the awesome efforts of the A-Team, we now have a system in place that can measure page load performance on a real network, the Web Page Test instance referenced above. Unfortunately, this instance is still being hosted under someone's desk, so I don't have a URL to hand out right now. Hopefully this landing will be enough to prove the project's worth, and we'll be able to get it out for wider use :) I ran tests of builds both with and without the patches in bug 881804 through the Web Page Test instance, and got some excellent results. For reference, the pages I tested with were https://www.facebook.com/ and https://mail.google.com/, and I tested each on both US broadband style networks (round trip times around 100ms), as well as a simulated 3G cellular network (round trip times around 300ms). The numbers for time from start of pageload until all data has been finished being transferred over the network improved exactly as expected, by about 300ms (3RTT) for the broadband connection, and about 900ms (also 3RTT) for the 3G connection. The more important number, though, is SpeedIndex ( https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index), which is effectively a metric that measures user-perceived speed in loading a page. On a broadband connection, SpeedIndex was improved by 5-10%, while on a 3G connection the improvement went up to 23%. This is a MAJOR win, both for the about-to-land patches and for this new test platform that the A-Team has worked so hard on (all at the request of us Necko folk). Any questions, please feel free to email me, either on-list or privately. -Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
