[TYPO3-core] Cachingframework implementation for lang sysext
lolli at schwarzbu.ch
Wed Jun 29 23:14:29 CEST 2011
On 06/29/2011 03:54 PM, Björn Pedersen wrote:
> Maybe the whole logic is to complicated:
> When will the ll-files change:
> a) if an extension is installed/updated
> b) if they are modified by hand
We should answer some questions to decide how a caching layer for lang
should look like:
- Is the parsing process 'expensive' at all? Is this profiled? I the
answer is a definate 'yes', we can benefit a lot from caching.
- Does it maybe make sense to rely on the first 'in memory' cache alone?
This would invalidate all clearing issues and we still have a cache for
consecutive calls of keys to the same ll file.
- How many ll files are typically parsed in a frontend / backend access?
For FE this probably depends heavily on the number of plugins that are
added to a page, but for BE I'd guess these are not too many, what do
you think? Do we have some numbers?
For the 2nd level cache itself: The current patch uses the fileBackend.
This will also trigger at least one filesystem request per ll file. If
you want to use the file backend for some reason, we could maybe also
think about using the PhpFrontend for this cache: This way we create a
.php file with the parsed target array, and we can require_once() it.
The nice benefit is that every php opcode cache will suppress the
filesystem access after the first require_once() to this file and we
will probably have a pretty quick solution.
BTW: We will need and get a generic phpfrontend cache in core sooner or
later anyway, for example I'd like to use it in the autoloader already.
For the cache invalidation: Until now we are trained that any BE actions
are 'non-cached', so until now if we changed a label, the backend
immediately recognized the label change. In the FE we are already
trained to clear caches frequently when developing, or we add &no_cache
param to the url to circumvent this. This is what people nagged with the
current implementation: The lang keys are not automagically refreshed if
we change a label anymore.
But I think Björn is correct at this point: Labels only change during
development, never (or very seldom) in production. From a performance
point of view I'd argue that effective caching in production is more
important than automagic cache clearing during development. Thus I'd
vote to have no cache clearing at all to reduce production overhead. For
development there is also be a very simple solution to switch off the
cache layer: Use the nullBackend in development context.
My 2 cents
More information about the TYPO3-team-core