1759708 - The DOMCacheThread uses a lot of CPU time after a restart for an update

Status: RESOLVED DUPLICATE of bug 1835120

(Core :: Storage: Cache API, defect)

Description

[Florian Quèze [:florian]]

Right after restarting for an update, I noticed in about:processes that the DOMCacheThread was using 100% of a core for a while (it has used a total of 18s of CPU time).

Here's a profile of it: https://share.firefox.dev/3w8YqCM

It seems to be doing many short sqlite queries:

Connection::stepStatement SELECT id, COUNT(response_headers.name) AS vary_count FROM entries LEFT OUTER JOIN response_headers ON entries.id=response_headers.entry_id AND response_headers.name='vary' COLLATE NOCASE WHERE entries.cache_id=:cache_id AND entries.request_url_no_query_hash=:url_no_query_hash AND entries.request_url_query_hash=:url_query_hash AND entries.request_url_no_query=:url_no_query AND entries.request_url_query=:url_query GROUP BY entries.id ORDER BY entries.id;

and
Connection::stepStatement DELETE FROM entries WHERE id IN

Would there be a way to make these queries more efficient?

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

janv, is this about the same issue that Cache does some validation after each update.
And if so, isn't this a dup of some old bug?

Comment 2

[Jan Varga [:janv]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #1)

janv, is this about the same issue that Cache does some validation after each update.
And if so, isn't this a dup of some old bug?

I could take a look but there are better experts for this area.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

The profile https://share.firefox.dev/3w8YqCM from comment 0 shows that we're servicing a large request issued via Cache.addAll. This is not the QM initialization sweep presumed in comment 1[1], but instead something else like a ServiceWorker being installed/updated.

I've filed bug 1835120 on improving the Cache API's profiler integration and I'm duping to it because:

• I believe this profile is probably fine (content doing a bunch of I/O is going to do a bunch of I/O) and so there are no next steps for this specific bug.
• It's clear there's low-hanging fruit to help everyone better understanding what's happening in a trace like this.

1: That said, QM init sweeps are a thing that can happen at startup after an upgrade.