Task #81438
closedStory #81432: Replace TYPO3 caching solution with PSR-6 / Doctrine capable alternative
Optional: recreate Typo3DatabaseBackend cache backend as PSR-6 implementation
0%
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.
Updated by Philipp Gampe over 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).
Updated by Christian Kuhn almost 3 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.
Updated by Christian Kuhn almost 3 years ago
- Status changed from Rejected to Closed