Project

General

Profile

Actions

Task #81438

closed

Story #81432: Replace TYPO3 caching solution with PSR-6 / Doctrine capable alternative

Optional: recreate Typo3DatabaseBackend cache backend as PSR-6 implementation

Added by Claus Due almost 7 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2017-06-02
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

TL;DR:

If dropping DB caching as TYPO3 native feature is rejected, then the DB based backend must be recreated.


Depending on how useful the DB cache routine is in the first place, the deprecated Typo3DatabaseBackend may be needed as a PSR-6 compatible solution that works with the new caching framework.

However, several arguments seem to indicate that a "filesystem first" strategy is much more appropriate:

  • Historically, DBMS could outperform filesystems quite easily, but this is far from the case these days.
  • Having SQL storage on remote servers becomes increasingly popular and performs quite poorly when caches are in DB.
  • Overall, keeping the DB connection clear of caching concerns and making it purely about actual data (thus easing things like improving DB performance and monitoring real usage uncluttered by cache usage).
  • Filesystem caches can be operated before installation is complete and requires no connections (and can be flushed even if DB connection is broken).
  • DB based caches are extremely vulnerable to schema issues and require an initialised schema; any change and the entire application may break.
  • And more

So it may be due time to reconsider our use of database caching in the first place. Signs point to either filesystem or third-party services being much more efficient and deployment/development-friendly as cache solutions.

Actions #1

Updated by Philipp Gampe almost 7 years ago

Do you have any numbers to back your claim that filesystem is going to by faster than DB?

Of course network might be slower than SSDs, but it might still be faster than disks. And DB data size usually does not count into the file system size limit on shared hosting.

Putting all caches on disk might result in hitting the limits of the filesystem (unlikely unless on share hosting) and the OS. Especially the later has a limit of open file handles that can easily be exceeded inside a cgroup. Of course this can be configured, but it should at least be considered.

I still think that a DB cache is a good solution for instances on shared hosting, which is properly about 90% of our user base (number made up).

Actions #2

Updated by Riccardo De Contardi over 6 years ago

  • Category set to Caching
Actions #3

Updated by Christian Kuhn about 2 years ago

  • Status changed from New to Rejected

Hey. It seems work in this area is completely stalled since 4 years. A couple of issues have been resolved, the cache API has been streamlined a bit.

I'm about to close the story and related issues for now: They are active action points, but stalled.

I guess if PSR-6 is picked up again, some solution would be different from what has been worked on 4 years ago. If single issues are still appropriate, they could be re-opened and re-attached to a new story again. Other than that, there seems to be little value in still keeping them open at the moment.

Actions #4

Updated by Christian Kuhn about 2 years ago

  • Status changed from Rejected to Closed
Actions

Also available in: Atom PDF