← Zurück zum Glossar
infrastruktur

Redis

In-Memory-Datenspeicher für Caching und Session-Management – reduziert Datenbankabfragen und macht WordPress-Seiten messbar schneller.

Aktualisiert: 23. Februar 2026

Was ist Redis?

Redis (Remote Dictionary Server) ist ein Open-Source In-Memory-Datenspeicher, der als Datenbank, Cache, Message Broker und Session-Store eingesetzt wird. Redis speichert Daten im RAM — Lesezugriffe sind typischerweise in unter 1 Millisekunde verfügbar, verglichen mit 5–50ms für MySQL-Abfragen. Dieser Geschwindigkeitsvorteil macht Redis zum Standard-Caching-Backend für hochperformante Webanwendungen.

Für WordPress-Betreiber ist Redis das wichtigste Werkzeug zur TTFB-Optimierung. WordPress führt pro Seitenaufruf standardmäßig 20–100 Datenbankabfragen durch. Mit Redis als Object Cache werden viele dieser Abfragen durch In-Memory-Lookups ersetzt — TTFB sinkt von typisch 200–500ms auf 30–80ms.

Kurzprofil Redis

Kurzprofil Redis

  • Typ: In-Memory-Datenspeicher (Cache, DB, Message Broker)
  • Entwickelt von: Salvatore Sanfilippo (2009), heute gesponsort von Redis Ltd.
  • Lizenz: RSALv2 und SSPLv1 (ab Version 7.4), ältere Versionen Apache 2.0
  • Datenstrukturen: Strings, Hashes, Lists, Sets, Sorted Sets, Streams, ...
  • Persistenz: Optional (RDB Snapshots, AOF Write-Ahead-Log)
  • Replikation: Master-Replica, Sentinel, Redis Cluster
  • Typischer Einsatz: WordPress Object Cache, Session-Speicher, Page Cache, Rate Limiting

Wie funktioniert Redis?

Redis hält alle Daten im RAM. Schreib- und Lesezugriffe erfolgen über ein einfaches Key-Value-Protokoll (RESP — Redis Serialization Protocol):

# Setzen (mit TTL von 3600 Sekunden):
SET cache:post:123 "{...JSON...}" EX 3600

# Lesen:
GET cache:post:123

# Löschen:
DEL cache:post:123

# TTL prüfen:
TTL cache:post:123  # → 3584 (Sekunden bis Ablauf)

Der wichtigste Redis-Befehl für WordPress ist GET — bei einem Cache-Hit liefert Redis die gespeicherten Daten in <1ms zurück. Bei einem Cache-Miss läuft der reguläre WordPress-Code (MySQL-Abfrage, PHP-Verarbeitung), das Ergebnis wird danach in Redis gespeichert.

Redis Datenbank-Isolation: Redis unterstützt logische Datenbanken (DB 0–15). Im WordPress-Stack werden typischerweise verschiedene Datenbanken für verschiedene Zwecke genutzt:

  • DB 0: WordPress Object Cache
  • DB 1: Page Cache (z.B. Souin)

Das verhindert, dass ein FLUSHDB für den Object Cache versehentlich auch den Page Cache löscht.

Eviction Policies: Wenn Redis an seine Speichergrenze kommt, entscheidet eine konfigurierta Eviction Policy, welche Schlüssel gelöscht werden:

  • allkeys-lru: Am seltensten verwendete Schlüssel zuerst — sinnvoll wenn Redis als reiner Cache verwendet wird
  • volatile-lru: Nur Schlüssel mit TTL werden verdrängt
  • noeviction: Fehler zurückgeben wenn voll — nur für persistente Datenspeicherung

Redis für WordPress-Betreiber

WordPress Object Cache Drop-In: WordPress hat eine eingebaute Object Cache API. Standardmäßig ist der Cache nur innerhalb eines einzelnen Requests persistent ("non-persistent"). Mit einem Redis-Drop-In (wp-content/object-cache.php) wird der Cache über Requests hinweg persistent — alle wp_cache_get()/wp_cache_set()-Aufrufe in WordPress-Core und Plugins nutzen dann Redis.

Installation:

wp --allow-root plugin install redis-cache --activate
wp --allow-root redis enable

Messbare Auswirkung: Typische TTFB-Werte für WordPress ohne/mit Redis:

  • Ohne Object Cache: 200–600ms TTFB
  • Mit Redis Object Cache: 30–100ms TTFB
  • Mit Redis + Page Cache: 5–20ms TTFB (statisch serviert)

Redis als Session-Speicher: WordPress-Sessions (bei Plugins wie WooCommerce) können statt in der Datenbank in Redis gespeichert werden — schneller und skalierbarer für Multi-Server-Setups.

Praxis-Tipps

Redis für WordPress

  • Plugin: Redis Object Cache (kostenlos) oder Redis Cache Pro (kommerziell, schneller)
  • Redis-Status prüfen: redis-cli ping → PONG
  • Cache-Stats: redis-cli INFO stats | grep keyspace_hits
  • Hit-Rate überwachen: Unter 80 % Hit-Rate deutet auf ineffizienten Cache hin
  • Speicher begrenzen: maxmemory 512mb + maxmemory-policy allkeys-lru in redis.conf
  • Datenbank-Trennung: DB 0 für Object Cache, DB 1 für Page Cache — nie FLUSHALL!
  • Monitoring: redis_exporter → Prometheus → Grafana

Was passiert ohne Redis?

Ohne Redis führt WordPress bei jedem Seitenaufruf alle Datenbankabfragen erneut aus. Bei einem Artikel-Aufruf sind das typischerweise 30–80 MySQL-Queries. Bei 1000 Besuchern pro Stunde sind das 30.000–80.000 Datenbankabfragen, die Redis auf wenige hundert reduzieren würde. Das direkte Ergebnis: höhere Serverauslastung, langsamere TTFB, schlechterer LCP.

Häufige Fragen

Redis vs. APCu — was ist besser für WordPress? Siehe APCu für den direkten Vergleich. Kurz: APCu ist schneller für Single-Server-Setups (direkt im PHP-Prozessspeicher), Redis ist besser für Multi-Server-Setups und bietet mehr Features (Persistenz, Datenstrukturen, Pub/Sub).

Gehen Daten verloren wenn Redis neu startet? Bei reinem In-Memory-Betrieb: Ja. Das ist für einen Cache akzeptabel — die Daten werden beim nächsten Zugriff aus der Datenbank neu geladen. Für persistente Daten (Sessions) sollte AOF-Persistenz aktiviert sein.

Verwandte Begriffe

FCP
start call_