| commit | 5179fdefa03c5d9af6f4da9c818aaeb84b38a500 | |
| author | Grisha Kruglov <gkruglov@mozilla.com> | |
| Thu, 23 Apr 2020 07:10:02 +0000 (23 00:10 -0700) | ||
| committer | Grisha Kruglov <gkruglov@mozilla.com> | |
| Tue, 12 May 2020 22:36:21 +0000 (12 15:36 -0700) | ||
| tree | 778ebb5e590e683cefb1402e1e9e464e5ebadd98 | treesnapshot (tar.gz zip) |
| parent | 8bc8a63583d1e79fb8c6d403ae9a505cde79f935 | commitdiff |
[components] Closes https://github.com/mozilla-mobile/android-components/issues/4992: Emit provider duration facts from BrowserAwesomeBar
Some things to consider and trade-offs:
When recording durations of various providers into a glean metric, we have a bit of a hurdle.
One approach would be to encapsulate all of the awesomebar-related perf telemetry entirely within the
awesomebar a-c component. But, set of providers isn't entirely known to us at the a-c level.
We know what providers we have defined, but we don't know what providers applications will provide themselves.
Also, glean doesn't have a metric of type (string->timespan), which would allow us to work-around this.
So, we can't define ping/metrics in the a-c component. This means that they need to be defined elsewhere, while
the measurement happens within the component. An established pattern for that in the codebase is emitting "facts",
which is what this patch does.
We delegate to the consuming application to then actually do something with these facts - e.g. map providers
to concrete glean metric definitions.
Another consideration is if we should try to group timings related to a single query. That's hard to do reliably,
and will introduce additional complexity into what's otherwise a super simple setup. Source of that complexity
is that we actively try to cancel query jobs as user is typing; our providers could take an arbitrary time to resolve,
and so grouping becomes difficult. However, we care about improving how long each individual provider takes,
since that's a good proxy for "how responsive is this UI?". Simply recording each individual timing we see
should be enough for that.
Some things to consider and trade-offs:
When recording durations of various providers into a glean metric, we have a bit of a hurdle.
One approach would be to encapsulate all of the awesomebar-related perf telemetry entirely within the
awesomebar a-c component. But, set of providers isn't entirely known to us at the a-c level.
We know what providers we have defined, but we don't know what providers applications will provide themselves.
Also, glean doesn't have a metric of type (string->timespan), which would allow us to work-around this.
So, we can't define ping/metrics in the a-c component. This means that they need to be defined elsewhere, while
the measurement happens within the component. An established pattern for that in the codebase is emitting "facts",
which is what this patch does.
We delegate to the consuming application to then actually do something with these facts - e.g. map providers
to concrete glean metric definitions.
Another consideration is if we should try to group timings related to a single query. That's hard to do reliably,
and will introduce additional complexity into what's otherwise a super simple setup. Source of that complexity
is that we actively try to cancel query jobs as user is typing; our providers could take an arbitrary time to resolve,
and so grouping becomes difficult. However, we care about improving how long each individual provider takes,
since that's a good proxy for "how responsive is this UI?". Simply recording each individual timing we see
should be enough for that.