Open Bug 1765686 Opened 11 months ago Updated 11 months ago

Bulk deletion of an entire cache could be optimized by offloading file deletion to another thread

Categories

(Core :: Storage: Cache API, enhancement, P3)

enhancement

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).

You need to log in before you can comment on or make changes to this bug.