Bug #101531
closed\TYPO3\CMS\Frontend\Middleware\PreviewSimulator::checkIfRootlineRequiresPreview causes horrible performance
0%
Description
When EXT:workspaces is installed, every frontend request where a BE user is logged in, triggers a TRUNCATE on both cache_rootline and cache_rootline_tags. This causes this cache to become empty for any subsequent frontend request, which causes terrible performance with multiple unnecessary SQL requests.
Additionally, it may cause the rootline cache to contain incorrect information (cache entries generated based on workspace state will be fetched by subsequent requests causing things like rootlines or access checks to potentially fail).
The problem occurs because \TYPO3\CMS\Frontend\Middleware\PreviewSimulator::checkIfRootlineRequiresPreview will indiscriminately flush this cache in the "finally" block of an exception catch, without any regard for whether or not a workspace other than LIVE is actually active.
Both of these problems - as well as multiple other potential cache-related problems stemming from the need to preview workspaces - may be completely circumvented by allowing CacheManager API to replace an active cache. The idea being that instead of indiscriminately flushing this and other caches, the cache backend can instead be replaced with a NullBackend on-the-fly when \TYPO3\CMS\Frontend\Middleware\PreviewSimulator::checkIfRootlineRequiresPreview determines that a workspace preview is necessary. Plus, only replacing these cache backends BE user's selected workspace is a non-LIVE workspace.
Doing so would mean that:
- There are no possible issues from a cached value that doesn't match the workspace state.
- The performance hit is isolated to whenever a workspace preview is actually happening.
- The actual cache is preserved and remains unmodified, removing the negative impact on other requests.
- No entries will be written to the substituted caches, removing the risk of retaining cached data that applies only to a workspace.
Updated by Claus Due about 1 year ago
Claus Due wrote:
When EXT:workspaces is installed, every frontend request where a BE user is logged in, triggers a TRUNCATE on both cache_rootline and cache_rootline_tags.
Correction: this doesn't require EXT:workspaces to be installed. It happens in EXT:frontend and is done whenever a BE user is logged in.
Updated by Claus Due about 1 year ago
A couple of deltas to demonstrate the severity of the problem:
- Not touching rootline cache at all: https://blackfire.io/profiles/compare/c302aae3-eb47-45de-af91-5c01b3108e60/graph (85% wall time, 99% I/O wait reduction).
- Adding a condition `if ($groupRestricted || $timeRestricted || $hidden) {` around the cache flush statements in the mentioned class: https://blackfire.io/profiles/compare/d6c265c5-7db1-412f-acc2-ac5a8f913211/graph (84% wall time, 99% I/O reduction).
- Experiment - forcing NullBackend on rootline cache indiscriminately in PreviewSimulator: $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] (83% wall time, 99% I/O wait reduction).
Updated by Christoph Lehmann 10 months ago
- Related to Bug #102205: Rootline cache gets flushed on every request when logged in backend user visits the frontend added
Updated by Christoph Lehmann 10 months ago
- Status changed from New to Needs Feedback
Does #102205 resolves your issue?
Updated by Georg Ringer 4 months ago
- Status changed from Needs Feedback to Closed
this should be fixed with #102205, therefore closing issue