Task #54984
closed
Epic #55070: Workpackages
Epic #55065: WP: Overall System Performance (Backend and Frontend)
Story #55073: review autoloader and language cache
"Clear all caches" makes the site unavailable for several seconds
Added by Rupert Germann almost 11 years ago.
Updated over 9 years ago.
Description
Clear all caches makes the site unavailable for several seconds. This is caused by the fact that the complete classloader cache is killed and rebuilt on this action.
And even more worse: If other requests are coming in during this "warm-up" progress, they fail with an exception in some cases because the autoloader doesn't find a required file.
to reproduce this open the Backend and the frontend in one Browser and one or more Frontends in other browsers, hit clear all caches in the backend and then hit F5 in the other browser windows. I mostly need only one or two tries to end up with a white page and an exception in the error log. (btw: my classloader cache is configured to use the memcached backend, so it can't be caused by a slow harddisk)
"clear all caches" happens quite often during clicking around in the backend.
for instance on:
- saving TS templates in Template module
- installing/de-installing extensions
- copying/moving pages recursively
- and some more ....
possible solution:
1. exclude the classloader cache from clear all caches
2. implement a more stable classloader cache rebuilding mechanism
- Parent task set to #52949
- Parent task changed from #52949 to #55073
- Category set to Performance
this issue is partly solved or at least mitigated by the introduction of "Caching Groups" (#54991)
now only the "Clear all Cache" button in the installtool and installing/removing extensions actually clears all caches including the packamanager/classloader caches.
if this has to happen, the site will still be unavaiable for several seconds:
I measured:
~ 4 seconds (cache_classes in APC),
~ 13 seconds (cache_classes in Files on a normal Harddisk) and
~ 40 seconds (cache_classes in Files on NFS)
in case another request hits the site during the cache rebuilding process, there's a good chance that this request causes a permanent fatal error. This leaves the caches in an inconsistent state which requires that someone logs in via SSH and removes typo3temp/Cache by hand.
Helmut had an idea how to tackle this problem in http://forge.typo3.org/issues/55029
- Status changed from New to Closed
composer classloader fixes this
This one should be re-opened.
I know it is fixed in 7.1 but since 6.2 is the only supported LTS at this time, and since it is LTS either the classloader or another bugfix should be done to 6.2 LTS as sites running NFS in production is breaking constantly for us when deploying new things that requires a cache clearing (a simple locallang update in an extension requires deep cache cleaning).
Anyone has a workaround for this? I'm honestly still confused to when and how this happens and how we can work around it (we recently started using a hosting platform based on NFS filesystem).
Agree with reopening. Clearing all caches in TYPO3 6.2 crashes the whole site for a few minutes.
Also agree with reopening! We have a big site with 6.2 wich is running on NFS. And we have the same problem.
I also agree with re-opening this issue : we have several websites running with typo3 6.2, some of them are multilingual. Every time we made a change in a locallang file (for example), we need to click on the "clear system cache" in the backend, but this action makes the site unavailable until we remove the typo3temp folder via SSH (no other solution has been found at the moment).
Agree with reopening! We have a big 6.2 site. Since 6.2 this problem occurs very often (nearly every day). If there isn't any solution, I'll have to migrate to 7.1. IMHO 6.2 is (atm) not usable for production purpose.
I'm not a developer hero but when I could help, I would try.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by