Bug #52125

Epic #55070: Workpackages

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

Bug #52949: Speed decrease since 4.5

Saving records takes ages to complete

Added by Xavier Perseguers almost 9 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Performance
Target version:
Start date:
2013-09-19
Due date:
% Done:

0%

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

Description

After Xhprof'ing a website to understand why it took about 17 seconds to save a record in Backend, I found that cache files (on disk) were read 130k times during the process!

Digging more in it, I found that the problem was that a few Core caches are configured by default with FileBackend which is extremely inefficient in its flushCacheByTag implementation because it basically needs to open and check each file in a row to check if it should be unlinked.

The big problem here comes on one hand from the "high" number of Cache files I have in my website:

  • 507 files in Cache/Data/t3lib_10n
  • 8 in cache_core
  • 1 in cache_phpcode
  • 35 in fluid_template
  • 1 in static_info_tables

(total = 552 files)

on the fact that on my production website I don't have SSD for storing data (which is typically the case) and on the other hand on the caching framework which basically is invoked on every cache Backend when a record is saved with a call like clearCacheByTag('page_<uid>') recursively for each page in the rootline. If you are a few levels deep, you end up with N * 552 files read for nothing because tags are not used anyway on those files.

I switched to APC for t3lib_l10n and the time dropped from 17 sec. down to 4 sec.

Suggestion

  • Try to change the default configuration from FileBackend to SimpleFileBackend for as much as many default configuration
  • Discuss if FileBackend should be changed, to possibly remove the "tag handling" and simply purge files or at least issue a big warning in documentation that this cache is extremely inefficient and the more cache files we have, the slower TYPO3 will be, no magic here.
  • Something else?

Related issues

Related to TYPO3 Core - Bug #52235: Timeout when copying pages recursively due to cache-clearing overloadClosed2013-09-24

Actions
Related to TYPO3 Core - Bug #34886: t3lib_cache_backend_FileBackend don't support 0 has liftimeClosedDominique Feyer2012-03-15

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

Also available in: Atom PDF