Looking at cold cache requests in the gander dashboard, there is an 80ms cache ::setMultiple() in EntityLastInstalledSchemaRepository. This prewarms per-entity-type caches for later requests. It is likely slow due to the size of the cache entries which are all pretty big.
This cache is cheap to build (it's one key/value query) and mainly exists to reduce memory usage on each request - because the data in key/value is much less than is needed on most requests. So if writing it later means more requests build it, that is OK if we can make the first-request-after-cache-clear return to the browser up to 80ms faster.
I think we can move it to the end of the request, and also avoid writing the cache items at all if they're already there.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screenshot from 2026-06-02 07-53-56.png | 392.5 KB | catch |
| #6 | Screenshot from 2026-06-02 07-49-53.png | 397.91 KB | catch |
| #5 | Screenshot from 2026-06-02 08-16-03.png | 394.43 KB | catch |
| #5 | Screenshot from 2026-06-02 08-15-54.png | 412.77 KB | catch |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
catchComment #3
catchPushed some initial work, but it's causing additional database queries so something is not right.
edit: this was a PHP notice causing a dblog write.
Comment #5
catchDeferring the write also saves a full mb of memory. Uploading screenshots from xhgui.
Uou can see the 1mb saving in the summary of the request (not in the screenshot), so even though it moves the mb to the end, because other memory has been freed up by that point, it doesn't increase the total.
Comment #6
catchAlso uploading a couple of screenshots from the gander dashboard running locally.
One shows the cache write happening near the beginning of the request and taking about 30ms. The other shows it happening alongside other post-response things like cache collector sets and taking 16ms. I think the time is just natural variation but it does show it as moving to the non-blocking part of the request.
The time spent in the method minus the cache write is about 4ms, so this really means that the cache write is much more expensive than the key value gets themselves. Even if more requests end up fetching from key/value than before, while their memory usage might be slightly higher, they won't be significantly slower, and the maximum peak memory usage is decreased overall.
Comment #7
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.