1648772 - Add individual markers for various asynchronous operations in nsHttpChannel at the opening phase

Status: NEW

(Core :: Networking: HTTP, enhancement, P3)

Description

[Honza Bambas (:mayhemer)]

We need to break down (actually get rid of!!) the "Waiting for socket thread" span and cut it to something actually meaningful.

nsHttpChannel goes through many asynchronous queries during the opening phase (before even going out to network) that are source of delivery delays.

• tracking annotation
• proxy resolution
• HTTP cache opening
• some more

All these are calling to background threads and get notified back to the main thread. Both background processing or main thread dispatch back can be delayed. We need this breakdown to understand the source of network response delivery in profiles.

Comment 1

[Honza Bambas (:mayhemer)]

I can't agree with Priority == P3. Missing this disallows analyzes of network response delays from profiles at all.

Comment 2

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Please feel free to change as you see fit, I don't have all the knowledge so that was my best guess compared to all the other things.

Comment 3

[Julien Wajsberg [:julienw]]

(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!

Comment 4

[Honza Bambas (:mayhemer)]

Yes, this is better to be in Necko. Keeping P2/S3, seems appropriate.