Transients verstehen und nicht nach Kalender löschen

Cookbook: Ziel und Ergebnis

Abgelaufene Transients dürfen entfernt werden; aktive Cache-Daten werden nur bei belegtem Fehler geleert. Eine Bereinigung behebt nicht die Komponente, die sie sofort wieder übermäßig erzeugt.

Rezept: Schritt für Schritt

1. Prüfen, ob ein persistenter Object Cache aktiv ist: dann liegen viele Transients nicht in wp_options.
2. Anzahl und Größe von _transient_% sowie zugehörigen Timeout-Einträgen rein lesend inventarisieren.
3. Ablaufstatus und Eigentümer bestimmen; WordPress-/WP-CLI-APIs statt ungezieltem SQL verwenden.
4. Nach Löschung Cache-Warmup und externe API-Last beobachten – ein Cache Stampede kann die Site zunächst langsamer machen.

Rechenweg oder Entscheidungsregel

Abgelaufen, wenn timeout > 0 und timeout < aktuelle Unix-Zeit\nWarmup-Kosten ≈ gelöschte aktive Schlüssel × mittlere Neuberechnungszeit

Praxisbeispiel

8.000 abgelaufene Transients belegen 180 MB; 40 aktive Produkt-API-Caches sparen je 400 ms und externe Requests. Nur die abgelaufenen werden per vorgesehenem Befehl entfernt. Ein Full Flush würde unnötig 40 teure Neuaufbauten gleichzeitig provozieren.

Prüfen, ob es funktioniert

• Tabellengröße und Anzahl abgelaufener Einträge sinken.
• Keine Spitze bei PHP-Workern, API-Fehlern oder Datenbanklast nach Bereinigung.
• Die verursachende Komponente erzeugt nicht sofort denselben Rückstau.

Rollback

Bei entfernten aktiven Transients gibt es meist keinen direkten Restore; sie werden neu erzeugt. Deshalb aktive Werte nur nach Backup/Export und in ruhigem Zeitfenster löschen. Bei Regression Eigentümer-Plugin prüfen und gespeicherten Zustand gezielt wiederherstellen.

Funktionsweise

Die Transients API speichert Daten mit einer maximalen Lebensdauer. Ein Transient darf vor Ablauf verschwinden, aber nie nach seiner Ablaufzeit zurückgegeben werden. Mit persistentem Object Cache liegen Transients gegebenenfalls außerhalb der Datenbank.

Was sinnvoll ist

Bei einer nachgewiesen aufgeblähten wp_options-Tabelle können abgelaufene Daten über WordPress- oder WP-CLI-Funktionen bereinigt werden. Verursacht ein Plugin sehr viele nie ablaufende Transients, muss dessen Verhalten und Version geprüft werden.

Was nicht sinnvoll ist

Alle Transients stündlich zu löschen ist keine Optimierung. Danach müssen APIs, Feeds, Abfragen oder Remote-Daten neu berechnet werden; das kann TTFB und externe Last erhöhen. Der Cache darf außerdem nicht als dauerhafter Datenspeicher missverstanden werden.

Erfolgskontrolle

Prüfe Tabellengröße, Anzahl abgelaufener Einträge und Serverzeit direkt nach der Bereinigung sowie im Normalbetrieb. Beobachte externe API-Limits und Cron-Last.

Quellen und Prüfstand

• WordPress: Transients API

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.