On a site with a large number of extensions and languages the loading time of /admin/reports/status can be very high due to how extensions translations are checked, even when local files only are used.
This is mainly due to having the locale_translation_get_file_history static cache being wiped out completely on every project/language check done.
* Create a Drupal site with a considerable amount of extensions (124 in my case)
* Enable a considerable amount of languages (59 in my case)
* Load the status page at /admin/reports/status
* Load time should be considerably high (over 1 min or fail with a 504 status in case of some proxies)
Implement the current todo note on making the static cache management more fine grained - i.e., clear only the entries needed.
Write tests
Review patch attached.
None.
None.
There are different issues that strive to modernize the usage of related functions and static caches - those are linked. Despite of changing those for a more modern approach they _might_ still suffer from the same inefficient cache invalidation issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | no_static_reset_on_translation_abstract_3309532.patch | 875 bytes | willempje2 |
| #4 | interdiff_3-4.txt | 477 bytes | pooja saraah |
| #4 | 3309532-4.patch | 2.24 KB | pooja saraah |
| #3 | 3309532-3.patch | 2.24 KB | pooja saraah |
| #2 | drupal-locale-translation-static-cache-3309532-2.patch | 2.25 KB | erickbj |
Comments
Comment #2
erickbj commentedComment #3
pooja saraah commentedFixed failed commands on #2
Attached patch against Drupal 9.3.x
Comment #4
pooja saraah commentedFixed failed commands on #3
Comment #5
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
To move forward this issue will need a test case to show the problem
Updated issue summary for it.
Comment #7
willempje2 commentedWhat worked for me was removing the additional `->timestamp` check when determining whether a translation history entry exists.
Even when the timestamp is `0`, the history entry should be treated as existing when creating this abstract.
My locale_file table is filled with 0 timestamp and 0 last_checked.
Comment #9
berdirThanks for reporting this. We're redesigning the history functions to handle caching better in #3037156: Modernize locale history functions. The current implementation does per-record invalidation on updates.
I also identified the repeated write backs with timestamp 0, but I think #7 is not the correct fix for that. timestamp 0 means there was not actually an import of that translation yet, so the type should not be set to that, it's misleading and might prevent an import of a local file. The timestamp should be set once an actual translation import happens. Instead, the else should only create a placeholder record if there is none yet. I have pending MR comment on the issue above to handle that.