Confirmed users
2,177
edits
TestEngineering/Performance/Glossary: Difference between revisions
TestEngineering/Performance/Glossary (view source)
Revision as of 14:09, 14 August 2020
, 14 August 2020Redirect to performance glossary
(Correct hyperlink) |
(Redirect to performance glossary) |
||
| (18 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
#REDIRECT [[Performance/Glossary]] | |||
{{DISPLAYTITLE:Glossary}} | {{DISPLAYTITLE:Glossary}} | ||
| Line 10: | Line 12: | ||
== DOM Content Flushed (dcf) == | == DOM Content Flushed (dcf) == | ||
This is a Mozilla proprietary extension and not part of the performance/navigation timing specification. It marks the completion of the first presentation flush after DOMContentLoaded. | |||
Internal Firefox metric activated by setting the preference dom.performance.time_to_dom_content_flushed.enabled to true. | |||
== Downstream == | == Downstream == | ||
Alert triggered by a commit that originally happened on another repo and was merged into the current one after. | |||
== First Contentful Paint (fcp) == | == First Contentful Paint (fcp) == | ||
First Contentful Paint (FCP) measures the time from navigation to the time when the browser renders the first bit of content from the DOM. | |||
== First Non-Blank Paint (fnbpaint) == | == First Non-Blank Paint (fnbpaint) == | ||
The timestamp of a shipped frame that contains the first paint to draw more than the document background. | |||
Has low value to a user, as this paint may be completely meaningless or useless. The first non-blank paint is often represented as "Start Render" in performance products. | |||
== Gecko profile == | == Gecko profile == | ||
The Firefox Profiler is a profiler that is built into Firefox and is available at profiler.firefox.com. It has tighter integration with Firefox than external profilers, and has more of a platform focus that the DevTools performance panel. It can be used a variety of situations where external profilers are not available, and can provide more information and insight into what the browser is doing. | |||
== mitmproxy == | == mitmproxy == | ||
| Line 30: | Line 34: | ||
== Noise (regarding performance tests) == | == Noise (regarding performance tests) == | ||
Generally a test reports values that are in a range instead of a consistent value. The larger the range of 'normal' results, the more noise we have. | |||
Some tests will post results in a small range, and when we get a data point significantly outside the range, it is easy to identify. | |||
= | The problem is that many tests have a large range of expected results. It makes it hard to determine what a regression is when we might have a range += 4% from the median and we have a 3% regression. It is obvious in the graph over time, but hard to tell until you have many future data points. | ||
== Perf Sheriff == | == Perf Sheriff == | ||
Using perfherder, a perf-sheriff will perform these tasks: | |||
# Look at the graph and determine the original branch, date, revision where the alert occurred | |||
# Look at Treeherder and determine if we have all the data. | |||
# Retrigger jobs if needed (more noise, more retriggers) | |||
# Once you have more data, look at the data in compare view to see if other tests/platforms have changed | |||
# Add all related alerts you see to the summary with the reassign button | |||
== Perfherder == | == Perfherder == | ||
Perfherder is an interactive dashboard intended to allow monitoring and analysis of automated performance tests run against '''Mozilla''' products (currently Firefox and Firefox for Android). | |||
== Raptor == | == Raptor == | ||
| Line 45: | Line 53: | ||
==RelMan glossary== | ==RelMan glossary== | ||
[https://wiki.mozilla.org/Release_Management/Glossary | [https://wiki.mozilla.org/Release_Management/Glossary These terms] are of use, especially when doing Performance sheriffing. | ||
== Retrigger == | == Retrigger == | ||
Any run of the same job on the same commit for the same repo triggered after the first one. | |||
Retriggers usually happen when the available datapoint in the graph are not enough for the sheriff to determine the culprit. | |||
== SETA == | == SETA == | ||
SETA finds the minimum set of jobs to run in order to catch all failures that our automation has found in the recent past on Firefox development repositories. | |||
SETA creates job priorities for all jobs found in the runnable-jobs API for that repository. | |||
== Talos == | == Talos == | ||
Talos is our versatile performance testing framework we use at '''Mozilla'''. It was created to serve as a test runner for the existing performance tests that '''Mozilla''' was running back in 2007 as well as providing an extensible framework for new tests as they were created. | |||
== Treeherder == | == Treeherder == | ||
Treeherder is a reporting dashboard for Mozilla checkins. It allows users to see the results of automatic builds and their respective tests. The Treeherder service manages the etl layer for data ingestion, web services, and the data model behind Treeherder. | |||
== Time To First Interactive (ttfi) == | == Time To First Interactive (ttfi) == | ||
This is a newer metric and reports when the page is first expected to be usable and will respond to input quickly (with the possibility of slow responses as more content loads). | |||
# Start looking for First Interactive at first contentful paint | |||
# Look for the first interactive window (with no regard to in-flight requests) | |||
# First Interactive is the start of the interactive window from step 2, first contentful paint or DOM Content Loaded, whichever is later | |||
== R/b == | == R/b == | ||
| Line 66: | Line 79: | ||
== WebPageTest == | == WebPageTest == | ||
Accurately measure, track, and report on key Firefox-performance metrics, over time. | |||