Project

General

Profile

Actions

Bug #52235

closed

Epic #55070: Workpackages

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

Bug #52949: Speed decrease since 4.5

Timeout when copying pages recursively due to cache-clearing overload

Added by Jan-Erik Revsbech over 10 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
Start date:
2013-09-24
Due date:
% Done:

100%

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

Description

We currently experience a problem resulting in timeouts when copying more than a few pages, especially if the site is mounted over NFS. The problem seems to arise due to several issues.

The clear_cache command i DataHandler calls $GLOBALS['typo3CacheManager']->getCache('cache_pages')->flushByTag('pageId_' . $pageId); for each page it calculates should be cleared (including siblings, and possibly parents, grand-parents etc.).
Since this will ask all registered caches to clear for the desired tag, this results in many, many checks for flush caching. Combine this with a massively inefficient cache FileBackend (see #52125) this results in timeouts when copying more that 3-4 pages.

The result is even worse, since the clear_cache is called for the page being copied AND for each content element on the page, and for each content element the cache is cleared for its PID (if using workspaces, there is yet another problem with this, but that seems to be fixed in another ticket).

So copying a page with 4 content elements, will clear cache for the page 5 times! And for each of these, the siblings and possibly parents are cleared as well.

I would suggest a few changes and would like some feedback on this:

1: Make sure that only the cache_pages and possibly cache_pagesection is cleared by only calling $GLOBALS['typo3CacheManager']->getCache('cache_pages')->flushByTag('pageId_' . $pageId);
2: Make DataHandler collect a list of all pages it wants to clear, and then defer the actual clearing to later, to make sure we only clear cache one time for each page. We could either defer until the destructor of DataHandler is called, or we could just put everything
3: As suggested in #52125 FileBackend should either be fixed, or not used by default.

Feedback is welcome. I will push a changeset to gerrit with the suggested changes when possible feedback is collected.


Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #52125: Saving records takes ages to completeClosed2013-09-19

Actions
Related to TYPO3 Core - Task #52295: Use SimpleFileBackend for t3lib_l10n cacheClosed2013-09-26

Actions
Related to TYPO3 Core - Bug #51116: Massive speed problem from TYPO3 version 6.x at the first page request after long periodClosed2013-08-16

Actions
Related to TYPO3 Core - Bug #61017: TCEMAIN.clearCacheCmd does not triggerClosedAlexander Opitz2014-08-18

Actions
Has duplicate TYPO3 Core - Bug #57265: Importing large amounts of data issues many truncate'sRejected2014-03-25

Actions
Actions

Also available in: Atom PDF