Closed
Bug 1183632
Opened 9 years ago
Closed 9 years ago
Non e10s submissions with child payloads.
Categories
(Toolkit :: Telemetry, defect)
Toolkit
Telemetry
Tracking
()
People
(Reporter: rvitillo, Assigned: gfritzsche)
References
Details
(Whiteboard: [unifiedTelemetry] [uplift4])
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
gfritzsche
:
review+
ritu
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
There is a high fraction (up to 10%), for recent build-ids, of non e10s saved_session submissions that have child histograms but don't have a browser window set to e10s. See [1]. Is this expected? [1] http://nbviewer.ipython.org/gist/vitillo/743c26f0a1fa71bd8f00
Reporter | ||
Updated•9 years ago
|
Flags: needinfo?(gfritzsche)
Reporter | ||
Updated•9 years ago
|
Flags: needinfo?(mconley)
Comment 1•9 years ago
|
||
jimm - could the child payloads be from plugin processes?
Flags: needinfo?(mconley) → needinfo?(jmathies)
Comment 2•9 years ago
|
||
Hmm, not sure. A couple thoughts - first we have child processes that run even when e10s is turned off. For example the background page thumbs service does this. Would that process collect GC_MS_children telemetry? I do not know. The other idea I had was that some users startup with e10s but then get prompted to disable and restart. This probably doesn't constitute a single session of telemetry data but I'm not 100% sure on that. I don't know what a saved_session can include.
Flags: needinfo?(jmathies)
Comment 3•9 years ago
|
||
Roberto, can you do some manual testing here? Trigger the thumbs service (talk to Tim Taubert) in single-process and see what kind of Telemetry is collected
Assignee | ||
Comment 4•9 years ago
|
||
Not sure offhand here, but it looks like investigation is ongoing already. Can we have any scenarios with e10s on but E10S_AUTOSTART==false, e.g. like the former "start e10s window" functionality?
Flags: needinfo?(gfritzsche)
Reporter | ||
Comment 5•9 years ago
|
||
I can confirm that in a non-e10s session the thumbs service generates a child payload with many histograms among which also GC_MS. George, is there a way to discern between the process type (e.g. content or thumbs service) in telemetry payloads?
Flags: needinfo?(gfritzsche)
Assignee | ||
Comment 6•9 years ago
|
||
So, per IRC the thumbnailing probably runs in the normal content process if e10s is on. So it should be enough to check if we are in a child and e10s is enabled via `Services.appinfo.browserTabsRemoteAutostart` and not enable Telemetry accordingly here: https://hg.mozilla.org/mozilla-central/annotate/2ddec2dedced/toolkit/components/telemetry/TelemetryController.jsm#l593 I wonder what fx versions are affected here, given storage cost server-side this could be shipping-relevant for unified telemetry.
Flags: needinfo?(gfritzsche)
Comment 7•9 years ago
|
||
vladan brought up a good point in IRC - if we're doing thumbnailing in the same content process, we risk janking the content process when generating the thumbnails. Sequestering the thumbnail generation into a separate content process, distinct from the ... uh, main? content process, might be a nice perf win. I've filed bug 1187441 about this.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → gfritzsche
Assignee | ||
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•9 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•9 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 8•9 years ago
|
||
This only initializes Telemetry in content processes if e10s is enabled. This exposed that the child histogram test is pretty fragile, so i made that more predictable.
Attachment #8639357 -
Flags: review?(alessio.placitelli)
Assignee | ||
Comment 9•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7233e84e726b
Comment 10•9 years ago
|
||
Comment on attachment 8639357 [details] [diff] [review] Non e10s submissions with child payloads Review of attachment 8639357 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. Nit: I would suggest changing the commit message to something a bit more descriptive about what the patch does. It's not mandatory, though, just a matter of personal taste.
Attachment #8639357 -
Flags: review?(alessio.placitelli) → review+
Assignee | ||
Updated•9 years ago
|
Whiteboard: [unifiedTelemetry] [uplift4]
Updated•9 years ago
|
tracking-e10s:
--- → +
https://hg.mozilla.org/mozilla-central/rev/060139fdfbfd
Status: ASSIGNED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox42:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Assignee | ||
Comment 13•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8641651 -
Flags: review+
Assignee | ||
Updated•9 years ago
|
Attachment #8639357 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 14•9 years ago
|
||
Comment on attachment 8641651 [details] [diff] [review] Don't generate child Telemetry payloads for the thumbnail service in non-e10s Approval Request Comment [Feature/regressing bug #]: Telemetry Unification [User impact if declined]: This is a fixup for Telemetry. We were submitting data for child processes with e10s off because of the Thumbnailer service. This has storage costs both client-side and server-side, also bandwidth costs. It is part of a mostly fixup & diagnostic uplift batch for 41: http://bit.ly/1LYhA16 [Describe test coverage new/current, TreeHerder]: We have automated test-coverage, it baked on Nightly. [Risks and why]: Low-risk, we haven't seen anything crop up on Nightly here. [String/UUID change made/needed]: None.
Attachment #8641651 -
Flags: approval-mozilla-aurora?
Comment on attachment 8641651 [details] [diff] [review] Don't generate child Telemetry payloads for the thumbnail service in non-e10s Approved since reporting childProcess telemetry data increases server storage even though this data is not needed in e10s-off mode.
Attachment #8641651 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 16•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/2fe3e641556d
You need to log in
before you can comment on or make changes to this bug.
Description
•