Task #39295

Epic #55070: Workpackages

Epic #55065: WP: Overall System Performance (Backend and Frontend)

Story #55076: review frontend rendering cache and rootline cache

Wrong expires date in cf_cache_pagesection

Added by Johannes Hahn about 3 years ago. Updated over 1 year ago.

Status:Resolved Start date:2012-07-26
Priority:Must have Due date:
Assigned To:- % Done:

100%
Category:Caching Spent time: -
Target version:6.2.0
TYPO3 Version:4.6 Complexity:
PHP Version:5.3 Sprint Focus:

Description

Hi,
don't know if its really a bug or just a miss configuration.

In table "cf_cache_pagesection" every expires timestamp is set to + 1 hour after
page generation. My config.cache_period = 86400 is ignored. So After one hour
the page cache is flushed.

In class t3lib_TStemplate function start near line 337
i changed if from:

$pageSectionCache->set(
  intval($GLOBALS['TSFE']->id) . '_' . $mpvarHash,
  $cc,
  array(
    'pageId_' . intval($GLOBALS['TSFE']->id),
    'mpvarHash_' . $mpvarHash
  )

to

$pageSectionCache->set(
  intval($GLOBALS['TSFE']->id) . '_' . $mpvarHash,
  $cc,
  array(
    'pageId_' . intval($GLOBALS['TSFE']->id),
    'mpvarHash_' . $mpvarHash
  ),
  //set timout else default 3600 is used
  $GLOBALS['TSFE']->get_cache_timeout()

then the expires date is correct.

Related issues

related to Core - Bug #50231: Caching framework broken - cache expires after 1 hour (cf... Resolved 2013-07-20

Associated revisions

Revision 097cd54e
Added by Andreas Wolf over 1 year ago

[BUGFIX] Very short lifetime for cache_pagesection

The default lifetime for the cache_pagesection is not set, so the
overall default of 3600 is used. This leads to the information in there
being repeatedly generated, though it does seldom change (it only
consists of information in the rootline, TypoScript configuration,
conditions etc.). Therefore, the lifetime is increased by this patch
again to 30 days. The cache is cleared nonetheless when clearing "all
caches".

The default lifetime for this cache was unlimited prior to the
introduction of the caching framework.

Change-Id: I98b307f11779174110ea2d5d79027771b44c5098
Resolves: #39295
Releases: 6.2, 6.1
Reviewed-on: https://review.typo3.org/27228
Reviewed-by: Ingo Schmitt
Tested-by: Ingo Schmitt
Reviewed-by: Stefan Froemken
Tested-by: Stefan Froemken
Reviewed-by: Oliver Klee
Reviewed-by: Andreas Wolf
Tested-by: Andreas Wolf

History

#1 Updated by Arjen Hoekema almost 3 years ago

Looks like the "cache_period" is only taken into account when setting the page cache. The "cache_pagesection" uses the defaultLifetime from the caching backend which is set to "3600".

For template cache stored in "cache_pagesection" I think the default lifetime should be set to "0" (unlimited) and not to the value of "cache_period". Caches are probably/mostly cleared using "Clear all cache" when modifications to the TS template are made by a backend user.

#2 Updated by Sven Tappert about 2 years ago

I created an extension that should fix the issue as you proposed it:
https://typo3.org/extensions/repository/view/cf_lifetime_patch (1.1.0+)

Since the issue still exists in 6.1.1 and probably above (#50231), the patch applies to all current branches from 4.5

If anyone has any suggestion or notices that the extension doesn't work properly, please let me know.

#3 Updated by Ernesto Baschny over 1 year ago

  • Status changed from New to Accepted
  • Target version changed from 4.6.11 to 6.2.0
  • Is Regression set to No

Good catch. It is true that config.cache_period only affects the page cache. This indeed makes sense, because this cache defines when a page rendering is repeated. The page cache is affected by "Cache Lifetime" in each page settings, then config.cache_period and config.cache_clearAtMidnight. Since 4.6 the page content is taken into account when calculating when the page cache expires (i.e. if you have a "starttime" element and it starts before the cache would expire, this lifetime is adapted accordingly). Great stuff (#20473).

This is all working well also in 6.x.

Now comes the "cache_pagesection". This contains the "configuration" of the pages (rootline, typoscript, conditions, etc). This is content-independant and usually should not expire so fast. In fact, in 4.5 it did not even expire at all (only when you hit "clear all caches").

Arjen interpreted it right:

This was not adapted when we introduced the caching framework for this (which was turned into the default in 4.6).

My suggestion would indeed be to rise this caching lifetime to something much higher than "1 hour" as it is today. Even "1 day" is too little in my understanding. The relevant caches are invalidated when something changes anyway. So we could cache this for a much higher lifetime (1 week or more) in my opinion and set this a new default.

I would not go for "unlimited" as this has caused some huge cache_pagesection-tables in the past. A decent default should suffice.

#4 Updated by Ernesto Baschny over 1 year ago

  • Priority changed from Should have to Must have
  • Parent task set to #55076

#5 Updated by Gerrit Code Review over 1 year ago

  • Status changed from Accepted 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 https://review.typo3.org/27228

#6 Updated by Gerrit Code Review over 1 year ago

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

#7 Updated by Gerrit Code Review over 1 year ago

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

#8 Updated by Andreas Wolf over 1 year ago

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

Also available in: Atom PDF