Project

General

Profile

Actions

Task #39295

closed

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 almost 12 years ago. Updated over 6 years ago.

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

100%

Estimated time:
TYPO3 Version:
4.6
PHP Version:
5.3
Tags:
Complexity:
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 1 (0 open1 closed)

Related to TYPO3 Core - Bug #50231: Caching framework broken - cache expires after 1 hour (cf_cache_pagesection & cf_cache_rootline)Closed2013-07-20

Actions
Actions #1

Updated by Arjen Hoekema almost 12 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.

Actions #2

Updated by Sven Tappert almost 11 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.

Actions #3

Updated by Ernesto Baschny over 10 years 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.

Actions #4

Updated by Ernesto Baschny over 10 years ago

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

Updated by Gerrit Code Review over 10 years 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

Actions #6

Updated by Gerrit Code Review over 10 years 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

Actions #7

Updated by Gerrit Code Review over 10 years 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

Actions #8

Updated by Andreas Wolf over 10 years ago

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

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF