Implement PFetch protocol and backing FetchService to allow Workers to request fetches without involving the main thread of their process
Categories
(Core :: DOM: Networking, enhancement, P3)
Tracking
()
Performance | P2 |
People
(Reporter: bkelly, Assigned: edenchuang)
References
(Blocks 5 open bugs)
Details
(Keywords: perf:pageload, Whiteboard: [necko-triaged])
Attachments
(5 files, 1 obsolete file)
Currently fetch() using nsIChannel on the main thread in the current process. This means that a worker thread (like service worker) can hit main thread jank when it tries to perform a network request. This is particularly bad for service workers since delaying the fetch() may in turn delay the network result for the main page load. The network team is working on making nsIChannel support PBackground so it can be used OMT. That will probably take a long time to fully happen, however. In addition, our service worker e10s refactor will move the service worker instances to a new process. That will also take some time to happen. Its also possible the memory overhead of this new process will be too large. An alternative we could do in the short term would be to implement a separate PBackground actor just for fetch(). We already support serializing Request and Response objects across IPC in the Cache API. In addition, Andrea recently landed parent-to-child AutoIPCStream support. Between these it might be easy to use PBackground to go to parent, proxy to main thread there, and then create the nsIChannel. If we did this, though, we would not be able to fully remove the current implementation. A PBackground fetch() would bypass the child-side service worker intercept today. We would only be able to use it in fetch() calls from within the service worker global itself. Eventually we could remove the old fetch() implementation after SWM is moved to the parent.
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
We may want to do this even with the necko changes. Right now I think they are only making OnDataAvailable() work OMT which means we still need to touch main thread for On(Start|Stop)Request(). Another factor to consider, though, is we would need to do something special for devtools. It currently requires nsIChannel in order to show up in the network monitor.
Updated•4 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Note: From a conversation with Dragana on Feb 14, 2019, I understand the plan is to make AsyncOpen, OnStart, and OnStop work off the main thread, so this bug probably wants to be duped.
Updated•3 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=1613912#c4 for the plan.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 4•1 year ago
|
||
Does this block parsing worklets as module scripts, i.e., bug 1572644?
Comment 5•1 year ago
|
||
(In reply to Anne (:annevk) from comment #4)
Does this block parsing worklets as module scripts, i.e., bug 1572644?
No. One could implement bug 1311726 while still performing the current "let's do all the network stuff on the main thread" behavior. Noting that right now the worklet script loader just assumes the one single invocation of WorkletFetchHandler that feeds into the module compilation.
The network-on-the-main-thread uses could then subsequently be replaced with PFetch later on.
Updated•11 months ago
|
Assignee | ||
Updated•9 months ago
|
Assignee | ||
Comment 6•3 months ago
|
||
Assignee | ||
Comment 7•3 months ago
|
||
Depends on D138812
Updated•3 months ago
|
Assignee | ||
Comment 8•2 months ago
|
||
Assignee | ||
Comment 9•2 months ago
|
||
Depends on D138813
Assignee | ||
Comment 10•2 months ago
|
||
Depends on D142436
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Comment 11•2 months ago
|
||
Depends on D142437
Description
•