TYPO3 v12/v13 Enterprise Caching: Redis-Backend gegen langsame Seitenaufrufe

TYPO3 ist im deutschsprachigen Raum das Rückgrat unzähliger Hochschulen, Konzerne und öffentlicher Institutionen. Das mächtige integrierte Caching-Framework speichert Cache-Einträge in Standardinstallationen jedoch direkt in relationalen Tabellen der MySQL- oder MariaDB-Datenbank (cf_cache_pages, cf_cache_rootline).

Bei großen Seitenbäumen mit Tausenden Unterseiten und mehrsprachigen Inhalten führt dies zu massiven Tabellen-Sperren (Table Locks), Fragmentierung und Time to First Byte (TTFB) Werten von über 1.500 Millisekunden.

Hier ist die praxiserprobte Anleitung, um TYPO3 mit einem performanten Redis In-Memory Caching Backend auszustatten.

1. Das Problem: Datenbank-Überlastung durch cf_cache_*

Überprüfen Sie den Zustand der Caching-Tabellen in Ihrer MySQL-Datenbank:

SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB` 
FROM information_schema.TABLES 
WHERE table_schema = 'typo3_db' AND table_name LIKE 'cf_%';

Häufig belegen Caching-Tabellen mehrere Gigabyte an Daten. Jeder Seitenaufruf erzeugt aufwändige SELECT- und UPDATE-Queries, die den I/O-Durchsatz Ihrer SSDs blockieren.

2. Redis-Anbindung in system/additional.php (oder LocalConfiguration.php)

Wir leiten die speicherintensiven Caches pages und hash direkt an eine lokale Redis-Instanz weiter:

<?php
// config/system/additional.php

$redisHost = '127.0.0.1';
$redisPort = 6379;

// 1. Pages Cache nach Redis
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['backend'] = 
    \TYPO3\CMS\Core\Cache\Backend\RedisCacheBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['pages']['options'] = [
    'hostname' => $redisHost,
    'port' => $redisPort,
    'database' => 0,
    'compression' => true,
    'defaultLifetime' => 86400, // 24 Stunden
];

// 2. Hash Cache nach Redis
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['hash']['backend'] = 
    \TYPO3\CMS\Core\Cache\Backend\RedisCacheBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['hash']['options'] = [
    'hostname' => $redisHost,
    'port' => $redisPort,
    'database' => 1,
    'compression' => true,
];

// 3. Rootline Cache nach Redis
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['backend'] = 
    \TYPO3\CMS\Core\Cache\Backend\RedisCacheBackend::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['rootline']['options'] = [
    'hostname' => $redisHost,
    'port' => $redisPort,
    'database' => 2,
];

3. TypoScript Optimierung: Keine uncached User-Functions im Header

Häufige Ursache für cache-brechende Latenzen in TYPO3 sind falsch deklarierte TypoScript-Objekte:

# ❌ Schlecht: USER_INT zwingt TYPO3, die Seite jedes Mal dynamisch neu zu rendern!
page.headerData.10 = USER_INT
page.headerData.10.userFunc = Vendor\Ext\Helper->renderTracking

#  Richtig: Standard USER-Objekt verwenden oder asynchron per Fetch API nachladen
page.headerData.10 = USER
page.headerData.10.userFunc = Vendor\Ext\Helper->renderTracking

4. Cache leeren & Speicher verifizieren

# TYPO3 Caches über die Konsole leeren
./vendor/bin/typo3 cache:flush

# Prüfen, ob Redis Schlüssel speichert
redis-cli -n 0 DBSIZE
# Zeigt die Anzahl der aktiven gecachten TYPO3-Seiten im RAM

5. Das Ergebnis: Stabile Millisekunden-Performance

Das System reagiert verzögerungsfrei, während die Datenbank vollständig von transienten Cache-Lasten befreit wird.

🔗 Zusammenhängende Systemdiagnosen & Infrastruktur-Geflecht:

Server- und Performance-Engpässe treten selten isoliert auf. Origin-Server-Latenzen, Datenbankstrukturen und Frontend-Metriken greifen direkt ineinander:

• Linux Kernel TCP BBR Aktivierung für Netcup & Hetzner: Paketverluste auf Mobilfunkverbindungen im DACH-Raum abfangen.
• Matomo On-Premise ohne Cookie-Consent als GA4-Ersatz: Datenschutzkonforme Webanalyse mit 100% Dateneigentum auf eigenem Server.
• MySQL InnoDB Buffer Pool Optimierung für Netcup & Hetzner: Festplatten-I/O eliminieren und Datenbank-Cache im RAM verankern.