Add markers for points of nsHttpChannel suspension and resume, track suspend time
Categories
(Core :: Gecko Profiler, enhancement, P2)
Tracking
()
People
(Reporter: mayhemer, Unassigned)
References
(Blocks 1 open bug)
Details
The network (or cached) response delivery can be delayed because some code or an extension simply suspends the channel from delivery.
Markers for each call to suspend() and resume() - with a stack, and tracking the overall time a channel is suspended is necessary to understand network response delivery delays.
|
Reporter | |
Comment 1•4 years ago
|
||
I can't agree with Priority == P3. Missing this disallows analyzes of network response delays from profiles at all.
|
||
Comment 2•4 years ago
|
||
Just curious, how is this bug different from bug 1625006? That bug is specific to suspensions that come from extensions, are there other common types of request suspensions?
|
|
Reporter | |
Comment 3•4 years ago
|
||
(In reply to Andrew Swan [:aswan] from comment #2)
Just curious, how is this bug different from bug 1625006? That bug is specific to suspensions that come from extensions, are there other common types of request suspensions?
Yes, number of components suspend and resume the channels. One example is classification, but there is more. I think this, more general bug should replace that bug.
|
|
||
Comment 4•4 years ago
|
||
A while ago I started an effort to improve the markers from bug 1625006 but I never found the time to finish it. However, a note from that effort: the extension framework suspends and resumes a network channel one time if there are multiple extensions with blocking listeners. I was working on improving this to create separate markers for each extension listener, but doing this would be at odds with the approach proposed here of moving the markers down into nsHttpChannel.{suspend,resume}. I think the higher level point is that the events that are meaningful in a profile don't necessarily map directly onto calls to suspend/resume.
I was also working on display information about extension channel suspensions in devtools (along with the existing profiler markers), though I don't think that would have any bearing on this bug. I can dust off the old incomplete patches if they would be useful...
|
||
Comment 5•4 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #1)
I can't agree with Priority == P3. Missing this disallows analyzes of network response delays from profiles at all.
Hey Honza,
As we discussed we haven't planned working on this soon in our team because our plate is already quite full for this year. So you told you'll look at it probably. Because this will be part of the network code, maybe this bug could be in your component, so that you have full control over the priority and severity?
This would still be linked to the Gecko Profiler work through the blocking bug.
Thanks!
|
|
Reporter | |
Comment 6•4 years ago
|
||
(In reply to Andrew Swan [:aswan] from comment #4)
A while ago I started an effort to improve the markers from bug 1625006 but I never found the time to finish it. However, a note from that effort: the extension framework suspends and resumes a network channel one time if there are multiple extensions with blocking listeners. I was working on improving this to create separate markers for each extension listener
That's a very good point! Then it may be good to simply have both markers - "internal" as proposed by this bug, and "external" as in bug 1625006, or something unifying it.
, but doing this would be at odds with the approach proposed here of moving the markers down into nsHttpChannel.{suspend,resume}. I think the higher level point is that the events that are meaningful in a profile don't necessarily map directly onto calls to suspend/resume.
I was also working on display information about extension channel suspensions in devtools (along with the existing profiler markers), though I don't think that would have any bearing on this bug. I can dust off the old incomplete patches if they would be useful...
(In reply to Julien Wajsberg [:julienw] from comment #5)
(In reply to Honza Bambas (:mayhemer) from comment #1)
I can't agree with Priority == P3. Missing this disallows analyzes of network response delays from profiles at all.
Hey Honza,
As we discussed we haven't planned working on this soon in our team because our plate is already quite full for this year. So you told you'll look at it probably. Because this will be part of the network code, maybe this bug could be in your component, so that you have full control over the priority and severity?This would still be linked to the Gecko Profiler work through the blocking bug.
Thanks!
Yes, I think most of the work will happen in Necko eventually. I'll schedule meetings to discuss the approach first.
Description
•