<div dir="ltr">Speaking as the primary Chromium developer in charge of this relevant code, I would like to caution putting too much trust in the numbers generated. Any statistical claims about the numbers are probably unreasonable to make.<div>
<br></div><div>Reasons:</div><div>* We don't actively maintain this code. It's behind the command line flags. They are broken. The fact that it still results in numbers on the benchmark extension is an example of where unmaintained code doesn't have the UI disabled, even though the internal workings of the code fail to guarantee correct operation. We haven't disabled it because, well, it's unmaintained.</div>
<div>* We don't make sure to flush all the network state in between runs, so if you're using that option, don't trust it to work.</div><div>* If you have an advanced Chromium setup, this definitely does not work. I advise using the benchmark extension only with a separate Chromium profile for testing purposes. Our flushing of sockets, caches, etc does not actually work correctly when you use the Chromium multiprofile feature and also fails to flush lots of our other network caches.</div>
<div>* No one on Chromium really believes the time to paint numbers that we output :) It's complicated. Our graphics stack is complicated. The time from when Blink thinks it painted to when the GPU actually blits to the screen cannot currently be corroborated with any high degree of accuracy from within our code.</div>
<div>* It has not been maintained since 2010. It is quite likely there are many other subtle inaccuracies here.</div><div><br></div><div>In short, while you can expect it to give you a very high level understanding of performance issues, I advise against placing non-trivial confidence in the accuracy of the numbers generated by the benchmark extension. The fact that numbers are produced by the extension should not be treated as evidence that the extension actually functions correctly.</div>
<div><br></div><div>Cheers.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 10:49 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Getting a grip on real web page load time behavior in an age of<br>
sharded websites,<br>
dozens of dns lookups, javascript, and fairly random behavior in ad services<br>
and cdns against how a modern browsers behaves is very, very hard.<br>
<br>
it turns out if you run<br>
<br>
google-chrome --enable-benchmarking --enable-net-benchmarking<br>
<br>
(Mac users have to embed these options in their startup script - see<br>
 <a href="http://www.chromium.org/developers/how-tos/run-chromium-with-flags" target="_blank">http://www.chromium.org/developers/how-tos/run-chromium-with-flags</a> )<br>
<br>
enable developer options and install and run the chrome web page benchmarker,<br>
( <a href="https://chrome.google.com/webstore/detail/page-benchmarker/channimfdomahekjcahlbpccbgaopjll?hl=en" target="_blank">https://chrome.google.com/webstore/detail/page-benchmarker/channimfdomahekjcahlbpccbgaopjll?hl=en</a><br>

)<br>
<br>
that it works (at least for me, on a brief test of the latest chrome, on linux.<br>
Can someone try windows and mac?)<br>
<br>
You can then feed in a list of urls to test against, and post process<br>
the resulting .csv file to your hearts content. We used to use this<br>
benchmark a lot while trying to characterise typical web behaviors<br>
under aqm and packet scheduling systems under load. Running<br>
it simultaneously with a rrul test or one of the simpler tcp upload or download<br>
tests in the rrul suite was often quite interesting.<br>
<br>
It turned out the doc has been wrong a while as to the name of the second<br>
command lnie option. I was gearing up mentally for having to look at<br>
the source....<br>
<br>
<a href="http://code.google.com/p/chromium/issues/detail?id=338705" target="_blank">http://code.google.com/p/chromium/issues/detail?id=338705</a><br>
<br>
/me happy<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave Täht<br>
<br>
Heartbleed POC on wifi campus networks with EAP auth:<br>
<a href="http://www.eduroam.edu.au/advisory.html" target="_blank">http://www.eduroam.edu.au/advisory.html</a><br>
<br>
_______________________________________________<br>
aqm mailing list<br>
<a href="mailto:aqm@ietf.org">aqm@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/aqm" target="_blank">https://www.ietf.org/mailman/listinfo/aqm</a><br>
</font></span></blockquote></div><br></div>