Extend Browsertime to collect select PerfStats
Categories
(Core :: Performance, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox87 | --- | affected |
People
(Reporter: acreskey, Assigned: acreskey)
References
()
Details
In Bug 1553254 we added the ability to record internal probes in a low-overhead manner.
These are useful for measuring specific timings that are easily lost within the noise of pageload.
This bug is to extend Browsertime so that we can extract chosen Perfstats for local analysis or use in automated performance tests.
The front-end for PerfStats is already in place.
https://phabricator.services.mozilla.com/D32878
And so it is expected that most of the work will be done in the browsertime repo:
https://github.com/sitespeedio/browsertime
Comment 1•4 years ago
|
||
Andrew do you have thoughts on the priority and severity of this bug? If so could you please update it. thank you.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
(In reply to Andrew Creskey [:acreskey] [he/him] from comment #0)
In Bug 1553254 we added the ability to record internal probes in a low-overhead manner.
These are useful for measuring specific timings that are easily lost within the noise of pageload.
This bug is to extend Browsertime so that we can extract chosen Perfstats for local analysis or use in automated performance tests.
The front-end for PerfStats is already in place.
https://phabricator.services.mozilla.com/D32878And so it is expected that most of the work will be done in the browsertime repo:
https://github.com/sitespeedio/browsertime
Eep! Andrew, just note that that front-end stuff never landed to the best of my knowledge. So privileged JS is the only way to get at PerfStats (your assertion that the work would be in BrowserTime though, is accurate).
Assignee | ||
Comment 3•4 years ago
|
||
(In reply to Kim Moir [:kmoir] ET from comment #1)
Andrew do you have thoughts on the priority and severity of this bug? If so could you please update it. thank you.
I'd like some input from the team on this one (I think it's quite important!), so we're going to discuss in next week's Performance Strategy meeting and I'll set a priority at that point.
Assignee | ||
Comment 4•4 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #2)
...
Eep! Andrew, just note that that front-end stuff never landed to the best of my knowledge. So privileged JS is the only way to get at PerfStats (your assertion that the work would be in BrowserTime though, is accurate).
Ah, good to know.
We can run privileged JS through Browsertime so this should work.
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
We discussed this in the Performance Strategy meeting and it was universally agreed that is high-value.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
:denispal landed this in upstream Browsertime
https://github.com/sitespeedio/browsertime/pull/1495/files/32bfc42f69eab1d37f8a234cdb1f21d233e64188..0aa07642bebf455bfbc2671baa1118c67f80a2fe
Assignee | ||
Comment 7•4 years ago
|
||
I should be able to extract the perfstats to report as the perftest metrics.
Assignee | ||
Comment 8•3 years ago
|
||
This change is integrated in our in-tree browsertime and we can also run performance tests that collect the metrics.
e.g.
https://searchfox.org/mozilla-central/rev/42ae3bea104c37a9986c6f18d17bd9ddb387129c/taskcluster/ci/perftest/windows.yml#178
Description
•