Bulk deletion of an entire cache could be optimized by offloading file deletion to another thread
Categories
(Core :: Storage: Cache API, enhancement, P3)
Tracking
()
People
(Reporter: asuth, Unassigned)
Details
The MDN ServiceWorker effort has reported high latencies due to the Cache API's per-origin thread blocking on deletion ~50k responses triggered via a single cache deletion taking >10 seconds. This will end up (async) blocking any Cache API calls from content as well as anything that tries to install, update, or spawn a ServiceWorker. This happens because Cache API uses an execution model similar to IDB but per-origin rather than per-database-per-origin were operations are run sequentially in a blocking fashion.
If we let file deletions be done async and farmed out to some kind of QM helper queue on its own thread/taskqueue that helps guarantee eventual deletion, we could speed this up somewhat. Database mutations would continue to need to block, but we expect that to be comparatively performant (although it might need to be done in multiple phases to handle partial deletions due to crashes/shutdown).
Description
•