Bug #50231

Caching framework broken - cache expires after 1 hour (cf_cache_pagesection & cf_cache_rootline)

Added by Sven Tappert about 9 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2013-07-20
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.1
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

The cache lifetimes (field "expires") in the tables "cf_cache_pagesection" & "cf_cache_rootline" are always set to the default of 3600 and disregards the TS config settings.

Therefore the cache of a page always expires after one hour. This disables the caching framework more or less and produces heavy server load. It seems the caching framework is broken in all current branches!

Example TS setup with cache lifetime of 7 days (page.config.x is set identically)

config.cache_period = 604800
config.cache_clearAtMidnight = 0

This results in incorrect "expires" values in tables "cf_cache_pagesection" and "cf_cache_rootline".

In issue #39295 there is a patch for the pagesection cache (in 6.x: TYPO3\CMS\Core\TypoScript\TemplateService.php about line 510).

I couldn't figure out yet where the rootline cache is set. The "expires" values in tables "cf_cache_hash" and "cf_cache_pages" are set correctly.


Related issues

Related to TYPO3 Core - Task #39295: Wrong expires date in cf_cache_pagesectionClosed2012-07-26

Actions
#1

Updated by Sven Tappert about 9 years ago

I created an extension that should fix the issue: https://typo3.org/extensions/repository/view/cf_lifetime_patch

Since the issue exists in all current branches, it includes different solutions for the 4.x and the 6.x branches of typo3.
Please let me know, if the patch doesn't work properly.

#2

Updated by Philipp Gampe about 9 years ago

Would you mind to push a patch to gerrit?

#3

Updated by Sven Tappert about 9 years ago

I will try, but I never pushed anything to gerrit. However, I would like to wait for some feedback from the cache developing team. One would probably choose a slightly different solution when directly patching the core.

#4

Updated by Philipp Gampe about 9 years ago

  • Status changed from New to Needs Feedback
#5

Updated by Philipp Gampe about 9 years ago

You can always configure all caches in AdditionalConfiguration.php as described in: http://docs.typo3.org/typo3cms/CoreApiReference/CachingFramework/Configuration/Index.html

#6

Updated by Sven Tappert about 9 years ago

Thank you Philipp, that's a very good hint!

However, it's not clear to me how one would simply change the global default cache lifetime or - alternatively - the individual cache lifetimes of the pagesection and rootline cache. Could you please post an example (4.x & 6.x)?

Isn't it such an essential topic, that it should be part of the "All Configuration" section in the Typo3 installer? I read a lot of posts & articles on Typo3 caching but none even mentioned that there is more about it than the TS configuration "cache_period".

#7

Updated by Philipp Gampe about 9 years ago

'SYS' => array(
      'caching' => array(
         'cache_pages' => array(
            'backend' => 'TYPO3\CMS\Core\Cache\Backend\Typo3DatabaseBackend',
            'options' => array(
               'defaultLifetime' => 3600, // lifetime in seconds
            ),
         ),
      ),
   ),

You can find all options in: http://docs.typo3.org/typo3cms/CoreApiReference/CachingFramework/FrontendsBackends/Index.html#caching-backend-options

Nevertheless, the default lifetime can be overridden by a concrete lifetime while a cache entry is set. The frontend should do this based on the TS configuration.

The rootline cache cannot be effected by the TS setting as it is used before the TS is know (chicken-egg problem). I am not sure about the pagesection cache. AFAIK the TS setting is only for the page cache.

#8

Updated by Sven Tappert about 9 years ago

Thank you a lot, that's the solution - but it is really quite hidden!

And the default behaviour is not nice, since a pagesection_cache with a short lifetime makes the config value for the page_cache almost useless, while administrators might wrongly assume to have complete control over the caching with the TS setup.

I will modify the "cf_lifetime_patch" extension to set the config values directly.
Would be great if it was at least in the installers "all configuration" or it would respect the TS setup in the future.

Philipp Gampe wrote:

AFAIK the TS setting is only for the page cache.

[...]
Nevertheless, the default lifetime can be overridden by a concrete lifetime while a cache entry is set. The frontend should do this based on the TS configuration.

Yes, that would be perfect, but the TS setup doesn't seem to be available upon cache creation. As far as I know even the final lifetime of the page cache has to be set in a second run, after the TS for the current page is rendered completely. Maybe this is a possible solution to other caches as well, to make them configurable via TS setup?

#9

Updated by Philipp Gampe about 9 years ago

If a page is in page cache, it is fetched from cache, even if the page_section cache already cycled out.

We could set the page section cache from TS, but I prefer configuring caches globally.

#10

Updated by Sven Tappert about 9 years ago

Philipp Gampe wrote:

If a page is in page cache, it is fetched from cache, even if the page_section cache already cycled out.

No, definitely not. That is probably what should happen, but please try it - after the pagesection cache expires (after 1 hour) the page is not fetched from cache!

#11

Updated by Philipp Gampe about 9 years ago

Hm, someone needs to take a look at the code.

#12

Updated by Harald no-lastname-given almost 9 years ago

Dear Sirs!

I am glad I found this report here. Maybe ones mentioned my problem is related to it.

http://forge.typo3.org/issues/51116

I've also thought about a bug in the cache lifetime. Now your post encouraged me.

Thank you very much

Harald

#13

Updated by Sven Tappert almost 9 years ago

Hi Harald, your issue is related but it's a seperate problem. Generating non-cached pages might take really a LONG time on typo3 6.x, especially when the TS setup grows.

However, you could try the patch extension "cf_lifetime_patch" to prevent the regeneration of already cached pages.

#14

Updated by Andreas Wolf over 8 years ago

  • Is Regression set to No

For cache_pagesection there is a patch pending in Gerrit (see #39295), for cache_rootline no such patch has been created, but that would be easy.

#15

Updated by Alexander Opitz about 8 years ago

As the mentioned issues #51116 and #39295 are already resolved.

Is something left to do here or can this issue be closed?

#16

Updated by Sven Tappert about 8 years ago

I have to do some testing. I'm not sure if the other issues were based on the same cause.

#17

Updated by Sven Tappert about 8 years ago

No, it's NOT fixed in 6.1.9. It's because the default values for:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_rootline']['options']['defaultLifetime']

and

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_rootline']

are not set correctly. They have to be set to \TYPO3\CMS\Core\Cache\Backend\AbstractBackend::UNLIMITED_LIFETIME; (i.e. 0).

So the FE cache still expires after 1 hour :-(

#18

Updated by Alexander Opitz about 8 years ago

  • Status changed from Needs Feedback to New
#19

Updated by Gerrit Code Review about 7 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/40659

#20

Updated by Christian Kuhn about 7 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#21

Updated by Gerrit Code Review about 7 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/40666

#22

Updated by Christian Kuhn about 7 years ago

  • Status changed from Under Review to Resolved
#23

Updated by Benni Mack almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF