Make important Telemetry session measurements reset per subsession

RESOLVED FIXED

Status

()

P4
normal
RESOLVED FIXED
4 years ago
3 months ago

People

(Reporter: gfritzsche, Unassigned)

Tracking

Trunk
Points:
1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [measurement:client])

(Reporter)

Description

4 years ago
Per the discussion on the FHR/Telemetry unification concerns [0] we want to go with client-side submission of both "reset per subsession" and "old style telemetry" histograms.

Bug 1127914 duplicates the histograms, this will take care of the measurements implemented in JS in TelemetrySession.jsm.

0:"Suggestions for the new unified FHR/Telemetry/Experiment ping", https://mail.mozilla.org/pipermail/fhr-dev/﷒0
(Reporter)

Updated

4 years ago
No longer blocks: 1069869
(Reporter)

Comment 1

4 years ago
Ok, i'm not entirely sure on the scope of this bug.

Benjamin, Vladan, do you have requirements on which JS implemented measurements we need to reset for the subsession data?
We have an overview of the main ping data here:
https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/toolkit/components/telemetry/telemetry/main-ping.html

Histograms (plain and keyed) are duplicated in bug 1127914 already.
Flags: needinfo?(vdjeric)
Flags: needinfo?(benjamin)
- Definitely reset simpleMeasurements.activeTicks when you start a new subsession. Talk to Avi about that.
- sm.debuggerAttached, sm.maximalConcurrentThreads and sm.js (setProto + customIter) should probably get reset, but these are not being used for much at the moment, and I'd be ok with not resetting them.
- Eventually, we should reset almost all Telemetry measurements when we start a new subsession.. BHR, slowSQL, chromehangs, main-thread I/O. Also future work
- The startup measurements technically only belong in the first subsession, but there's no harm (and there is some benefit) to not resetting them
- Some measurements should never be reset, e.g. UITelemetry
- For the time-being, resetting the histograms is sufficient

- You might need to ask someone else what to do with the FHR probes when a new subsession begins
Flags: needinfo?(vdjeric)

Comment 3

4 years ago
For now, we don't need to divide BHR, slowSQL, chromehangs, UITelemetry, or main-thread IO, and we can submit those only with the last subsession.

In the future we'll want to divide BHR, slowSQL, chromehangs, and main-thread IO, but I don't know what we want to do with UITelemetry (I want to spend some time understanding that mechanism more thoroughly anyway, from a privacy perspective).
Flags: needinfo?(benjamin)
(Reporter)

Comment 4

4 years ago
Thanks, this definitely doesn't need work for phase 2 then.
Blocks: 1120356
No longer blocks: 1127919
(Reporter)

Comment 5

4 years ago
From what i gather here, we should be good with duplicating simpleMeasurements.activeTicks for subsessions for now.
Moved that to bug 1137222 and this bug to a later phase.
Blocks: 1122482
No longer blocks: 1120356
Priority: -- → P3

Comment 6

3 years ago
task is to break this bug into discrete items, then size those for q4
Points: --- → 1
Whiteboard: [measurement:client]
(Reporter)

Updated

3 years ago
Summary: Duplicate JS telemetry data for double submission → Make important Telemetry session measurements reset per subsession
(Reporter)

Updated

3 years ago
Priority: P3 → P4
With the saved-session ping gone we know that all relevant stuff is already reset on subsessions.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
See Also: → bug 1443603
You need to log in before you can comment on or make changes to this bug.