Skip EventQueues for ODA and OnDataFinished
Categories
(Core :: Networking, task, P3)
Tracking
()
People
(Reporter: smayya, Assigned: smayya)
Details
(Whiteboard: [necko-triaged])
Attachments
(7 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
117.03 KB,
text/plain
|
Details | |
23.27 KB,
text/plain
|
Details | |
181.84 KB,
text/plain
|
Details |
This bug will investigate the cause of delays between dispatching OnDataAvailable in the event queue and running OnDataAvailable in the arget thread.
This bug will also design a dispatch mechanism to skip the channel event queue.
Assignee | ||
Updated•2 months ago
|
Assignee | ||
Comment 1•2 months ago
|
||
Assignee | ||
Comment 2•2 months ago
|
||
Updated•2 months ago
|
Comment 3•2 months ago
|
||
Updated•2 months ago
|
Comment 4•2 months ago
•
|
||
This is ontop of the rebased new dispatch logic from Sunil. I also flipped the pref to turn off OMT decompression again, since I couldn't figure out how to have the patch that already did that apply here.
Comment 5•2 months ago
|
||
Experiment
Procedure
Using the logging added in patch D232054 we figured out that we could reliably get a difference >10ms in the delta's between OnStartRequest dispatch/start and OnDataAvailable dispatch/start (which means there is room for improvement using a direct dispatch and skipping the queue) when visiting cnn.com
while having the netmonitor open (F12 -> navigate to "Network").
Then we added logging in patch D233038 on top of the new dispatch logic from patch D231986 to validate if the direct dispatch would improve those latencies.
The tests have been run by filtering the logs with the MOZ_LOG=nsHttp:5 ./mach run |& grep "<FILTER>" |& tee ~/log-<FILTER>.txt
command. For each of the filters ("OMT Experiment", "DIRECT DISPATCH", "QUEUE") the website has been loaded 5 times. The logs can also be found attached to the bug.
Findings
TLDR
Using direct dispatch significantly reduced the amount of latency between OnDataAvailable dispatch/start and apart from a few outliers there are no diffs >10ms left.
Detailed
When looking at the log-omt.txt
file where the output was filtered for "OMT Experiment", i.e. capturing all logs that indicate big deltas, and searching that file for "DIRECT DISPATCH" we see:
- there are only 2 lines indicating a diff >10ms, but both of those barely make it above the threshold
- all the lines indicating a diff >10ms that went through the queue have a diff of 20ms+ going up to 42ms
- only 2 of the 12 diffs >10ms are from direct dispatch
- there are no deltas >100ms for OnDataAvailable dispatch/start when going through direct dispatch
In log-direct.txt
where the output was filtered for "DIRECT DISPATCH", i.e. capturing all logs where a request went through direct dispatch we can see:
- There have been many requests that went through direct dispatch (meaning the above findings are not due to lack of requests using the new logic)
- only one line containing "OMT Experiment" that was caused by a request producing a diff >10ms, but without having a big OnDataAvailable delta
In log-queue.txt
where the output was filtered for "QUEUE", i.e. capturing all logs where the request went through the queue we can see:
- 115 lines containing "OMT Experiment" that are indicating a diff >10ms or a OnDataAvailable delta >100ms
- 10 of those 115 are from a diff >10ms, 9 of those >20ms
Comment 6•2 months ago
|
||
Comment 7•2 months ago
|
||
Comment 8•2 months ago
|
||
Description
•