Collect telemetry on time spent in IPC method when Fission is enabled
Categories
(Core :: Performance: General, enhancement, P2)
Tracking
()
Fission Milestone | M6 |
People
(Reporter: ccd, Assigned: beth)
References
Details
Attachments
(1 file)
1.96 KB,
text/plain
|
chutten
:
data-review+
|
Details |
Collect telemetry on the time spent on sync IPC methods when Fission is enabled. There are
big IPC methods in early Fission development and determining their impact is key.
Comment 2•6 years ago
|
||
Sean said he'll work on adding this.
Comment 3•6 years ago
|
||
It isn't clear what this bug is about. P2 because this is assigned, but neha, could you perhaps provide a bit
more context here so that also whoever will review this knows what we should be measuring.
(or forward the ni? to who might know :) )
Comment 4•6 years ago
|
||
The Performance team recommends we measure how much time we spend blocked in sync IPC. OTOH, I'm not sure what we will compare those measurements against to decode whether the sync IPC time is too long or good enough. And if we see lots of time in sync IPC, will we know which sync IPC messages are causing the most delays?
@ Corey, what questions do we want to answer with this probe?
Comment 5•6 years ago
•
|
||
Why is this sync IPC any more horrible in Fission vs. non-Fission?
(of course currently session-history-in-parent-process uses sync IPC, but we can't ship any of that)
Updated•6 years ago
|
Reporter | ||
Comment 6•6 years ago
|
||
One use of this probe is measure how we are doing in time reducing being block in sync IPC through time, as development in Fission progresses. As per Kris, we are adding a lot of these methods early on in Fission development. As these are removed, or changes are added to reduce the blockage, this probe would be useful in measuring the impact. We cannot know which IPC methods are causing the most delays; however, we will know the impact of the ones that get removed, or changes are made to affect their blockage.
Kris, could provide additional information as to why this probe would useful?
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 7•5 years ago
|
||
Move Fission telemetry probe bugs from M5 dogfooding milestone to M6 Nightly.
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 8•5 years ago
|
||
:ccd, what exactly should the telemetry be capturing? Should this be submitting scalars of durations spent in all each sync IPC method? eg inside SendGetLoadedInThisProcess
?
Reporter | ||
Comment 9•5 years ago
•
|
||
:barret I believe that is the intention of the probe. To submit a scalar of durations spent in all sync IPC methods.
Assignee | ||
Comment 10•5 years ago
|
||
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
I talked with :nika about this, and we have existing telemetry that can be used (IPC_SYNC_MAIN_LATENCY_MS) which can be correlated with telemetry for the telemetry for fission.autostart
.
Updated•5 years ago
|
Description
•