Problem/Motivation

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

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

berdir created an issue. See original summary.

berdir’s picture

#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

berdir’s picture

quietone’s picture

Version: 11.1.x-dev » 11.x-dev

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.