Active
Project:
Drupal core
Version:
main
Component:
configuration system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jan 2025 at 12:07 UTC
Updated:
7 Jan 2025 at 00:05 UTC
Jump to comment: Most recent
We initially didn't add caching to this because it would need to be invalidated fairly frequently with cache tags.
However, some of these calls can be fairly frequent and aren't cached (enough), specifically LanguageManager::getLanguages().
Comments
Comment #2
berdir#3476421: Add assertions to OpenTelemetryNodePagePerformanceTest::testNodePageCoolCache() shows 3 queries from listAll()/findByPrefix(). The mentioned LanguageManager::getLanguages(), which isn't cached and happens early on all pages, field.field.%, which is likely due to loading field config entities and should already be pretty well cached then. And then one for workflows.
Took me a bit of time to debug through the right page to identify those 3. The third is coming from \Drupal\content_translation\Access\ContentTranslationDeleteAccess::checkAccess(), which loads all worfkflows and separately adds them as a cache dependency. That seems unnecessary. If we depend on any of them existing, then this wouldn't cover new ones, and it seems easier and more efficient to just add the list cache tag then.
While stepping through, I also saw a lot of additional lookups. Mostly to check for entity bundles, but also some other stuff, but typically in well cached places. views data for example indirectly triggers a lot of them, like checking if any action config entities exist.
Tempted to won't fix this and instead file two specific issues to add caching to LanguageManager and improve ContentTranslationDeleteAccess
Comment #3
berdirCreated #3497340: Improve cache dependencies in ContentTranslationDeleteAccess and implementation of ContentTranslationManager::isPendingRevisionSupportEnabled
Comment #4
berdirAnd #3497341: Add caching to ConfigurableLanguageManager::getLanguages()
Comment #5
quietone commented