This repository has been archived by the owner on Feb 20, 2023. It is now read-only.
Add telemetry probe for dex load time #8803
Labels
Projects
Comments
It may be valuable to revisit the cold/warm/hot startup definition doc here. |
Alessio suggested we can use Glean performance metrics to capture these effectively. |
mcomella
moved this from Needs prioritization
to In progress
in Performance, front-end roadmap
Feb 27, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Feb 28, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Feb 28, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 13, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 13, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 13, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 13, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 13, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 18, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 18, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 18, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 18, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 18, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 19, 2020
During glean review, keeping as a separate commit to easily see the diff.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 19, 2020
During glean review, keeping as a separate commit to easily see the diff.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 19, 2020
During glean review, keeping as a separate commit to easily see the diff.
Waiting on ecsmyth to determine if time for |
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 31, 2020
This wraps a Glean TimespanMetricType to make it safer to measure duration.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Mar 31, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 9, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 9, 2020
We need to access the data in stat to get the process start time, so we can calculate the time from process start until application.init for the frameworkStart probe.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 9, 2020
This class controls the central logic around the metrics we want to record.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 9, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 15, 2020
We primarily want to determine if this is a problem area for us to investigate rather than a long term measurement to keep so we should set the expiration date accordingly. Furthermore, this code executes before crash reporting is init so it's ideal to remove it sooner rather than later.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 15, 2020
…t capture methods.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
We need to access the data in stat to get the process start time, so we can calculate the time from process start until application.init for the frameworkStart probe.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
This class controls the central logic around the metrics we want to record.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
We primarily want to determine if this is a problem area for us to investigate rather than a long term measurement to keep so we should set the expiration date accordingly. Furthermore, this code executes before crash reporting is init so it's ideal to remove it sooner rather than later.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
…t capture methods.
mcomella
added a commit
to mcomella/fenix
that referenced
this issue
Apr 16, 2020
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
We need to access the data in stat to get the process start time, so we can calculate the time from process start until application.init for the frameworkStart probe.
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
This class controls the central logic around the metrics we want to record.
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
We primarily want to determine if this is a problem area for us to investigate rather than a long term measurement to keep so we should set the expiration date accordingly. Furthermore, this code executes before crash reporting is init so it's ideal to remove it sooner rather than later.
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
mcomella
added a commit
that referenced
this issue
Apr 17, 2020
I added the "dex launch time" probe: the time between process start and |
mcomella
changed the title
Add telemetry probe for startup time
Add telemetry probe for dex load time
Apr 20, 2020
I'm going to close as fixed and create a new issue for the analysis. |
Filed #10161 for the analysis. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
edit: this issue was repurposed to only instrument dex load time instead of startup time but the description for startup probes remain below.
Why/User Benefit/User Problem
Startup time is an oft cited reason for friction and churn. We need to understand how long it takes Fenix to startup for our users so that we can prioritize work to address regressions and outliers that result in decreased engagement or churn. Local and CI-based testing provides an incomplete picture of how Fenix performs at startup.
Impact
Improved understanding of how Fenix performs on startup for our users.
Acceptance Criteria (how do I know when I’m done?)
We should make a best-effort to incrementally instrument as much of startup as possible - until we hit diminishing returns - because it's impossible to do it all. Unfortunately, it will be difficult to define what this looks like in advance so take this as a guiding principle. Msg mcomella if this does not make sense.
Some incremental steps we should try to implement for GA:
FenixApplication.onCreate
(this may or may not be helpful but we want to add it to see if it is in practice)FenixApplication.onCreate
until first frame drawnSome incremental steps we probably can't implement by GA but we should verify:
FenixApplication.onCreate
until visual completenessHere is ecsmyth's ideal startup time probe that inspired these incremental steps:
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: