1497997 - [meta] GeckoView performance telemetry metrics

Status: NEW

(GeckoView :: General, enhancement, P3)

Description

[Eugen Sawin [:esawin]]

Let's discuss the telemetry probes that would be useful for our GeckoView performance dashboard in this bug. We can handle adding additional probes in dedicated bugs if required.

1. Startup time:
It's tricky to account for all the different GV usage scenarios for this metric. To start, we could track the time between the initialization of the runtime and the Gecko-ready state.

2. Actual page load time:
Adding the GV-equivalent probe to FX_PAGE_LOAD_MS would give us the overall (non-dynamic) page load time metric.
There are existing Gecko probes that track this time, but are either not sent or are in some other way less useful on mobile, e.g., TOTAL_CONTENT_PAGE_LOAD_TIME tracks a useful time, but has its limit set too low at 30s.
We probably want to control this probe to ensure that it's directly relatable to the perceived page load time probe.

3. Perceived page load time:
The goal of the progress tracker (ProgressDelegate.onProgressChange) is to track and signal the perceived page load progress. We should add a probe to track load completion times.
This probe will also be useful for the validation and tweaking of the signals used to track the perceived load progress.
TIME_TO_NON_BLANK_PAINT_MS is also a useful probe to track the time to the initial non-blank paint.

4. Memory usage:
There are a number of MEMORY_* candidate probes, we should look into which provides the strongest signal on mobile.

Do this metrics cover the performance fundamentals we care about?
Are there existing better suited probes than the ones suggested?

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Sounds reasonable to me. I think James and Vicky will have more interesting comments. Adding Anthony because he probably has good ideas about measuring memory.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

I think this is a good start. I'd also like to know about child process startup time, so we should factor that into the startup stuff.

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Eric can advise on memory probes.

Comment 4

[Eric Rahm [:erahm]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3)
> Eric can advise on memory probes.

I'd need more details on how geckoview works. Is it in it's own process, or a library in another process? All the MEMORY_* metrics are process-centric which makes sense for measuring Firefox as a whole, but if you're embedded in another process it will include that process' memory too. I'll breakdown the measurements for you:

*MEMORY_TOTAL*

For e10s this is RSS [1] chrome process + USS [2] of child processes, it's pretty useful for calculating overall impact. Single process this is just the RSS.

*MEMORY_UNIQUE*

This is just the USS of each process (not summed). This might be useful if you are using content processes, but embedded in a parent process. It's filterable by process type.

*MEMORY_UNIQUE_CONTENT_STARTUP*

This is the USS of each content process at startup. It's useful for measuring the baseline overhead of each process. We're using it for fission memshrink work.

*MEMORY_VSIZE*

This is the VSS [3] (virtual set size) of each process. It's most useful for measuring impact on 32-bit processes due to limited address space.

*MEMORY_VSIZE_MAX_CONTIGUOUS*

This is probably windows only, it helps identify problems with address space fragmentation (particularly on 32-bit).

[1] https://en.wikipedia.org/wiki/Resident_set_size
[2] https://en.wikipedia.org/wiki/Unique_set_size
[3] https://en.wikipedia.org/wiki/Virtual_memory

Comment 5

[Eugen Sawin [:esawin]]

Vicky, we do have some new GV-specific page load and startup performance probes.
I can add them to the Android health dashboard if you agree that they are useful to track regressions.

https://sql.telemetry.mozilla.org/queries/61072/source#157446
https://sql.telemetry.mozilla.org/queries/61074/source#157450
https://sql.telemetry.mozilla.org/queries/61075/source#157452
https://sql.telemetry.mozilla.org/queries/61076/source#157454

Comment 6

[Benjamin De Kosnik [:bdekoz]]

Eugen, the performance team is using these 5 telemetry probes to track page loads on desktop ATM:

TIME_TO_DOM_COMPLETE_MS
TIME_TO_DOM_CONTENT_LOADED_END_MS,
TIME_TO_LOAD_EVENT_END_MS
TIME_TO_NON_BLANK_PAINT_MS
FX_PAGE_LOAD_MS_2

Can you let me know more about how GV_PAGE_LOAD_PROGRESS_MS relates to these existing probes? If you can track FX_PAGE_LOAD_MS_2 in this dashboard then yes, that would be useful.

Ideally, desktop and mobile would share a common naming schema for these stuff (maybe even using the W3C navigation timing names!) instead of the current split.

Can you send me more background info (email is fine) about how you are getting these performance probes out of GV on android? mozconfig, and prefs or configs, logs, etc. Thanks!

Comment 7

[Chris Peterson [:cpeterson]]

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9

Comment 8

[Chris Peterson [:cpeterson]]

Tasks and enhancements should have severity N/A.