DevOps 13 Min Lesezeit

Redis als Cache auf dem VPS 2026 – Setup & Tuning

Warum Redis als Cache auf dem VPS 2026 noch immer Standard ist

Redis hat 2026 seinen 17. Geburtstag hinter sich und ist trotzdem weiterhin der De-facto-Standard für In-Memory-Caching auf selbst gehosteten Systemen. Der Grund ist simpel: Kaum ein anderes Tool liefert bei so geringem Betriebsaufwand so viel Leistung. Auf einem VPS mit 4 vCPU und 8 GB RAM erreicht ein korrekt konfigurierter Redis-Server über Loopback Latenzen von 0,05 bis 0,15 ms pro GET – das ist rund 200-mal schneller als ein Zugriff auf eine lokale NVMe-Datenbank und rund 400-mal schneller als ein Netzwerk-Roundtrip zu einem externen Managed-Cache.

Der typische Anwendungsfall auf einem VPS ist ein klassischer Cache-Aside-Layer: Die Anwendung fragt zuerst Redis, bei einem Miss wird aus MySQL oder PostgreSQL gelesen und das Ergebnis mit TTL in Redis abgelegt. Bei WordPress reduziert das die Query-Zahl pro Seitenaufruf von 40–80 auf 2–5, bei Laravel sinkt die Antwortzeit von 180 ms auf 25–40 ms, bei Node.js-APIs lassen sich Rate-Limits und Sessions komplett aus der Datenbank herausziehen.

2026 gibt es allerdings eine wichtige Neuerung: Seit der Lizenzumstellung auf AGPLv3 im Jahr 2024 hat sich der Fork Valkey unter dem Dach der Linux Foundation etabliert. Valkey 9.x ist protokollkompatibel und in vielen Distributionen bereits der Standard-Ersatz. Für reines Caching macht das im Alltag kaum einen Unterschied – beide sprechen RESP3 und verhalten sich bei den hier gezeigten Konfigurationen identisch. Wer maximale Rechtssicherheit braucht oder auf BSD-Lizenzen angewiesen ist, nimmt Valkey; wer die neuesten Redis-8.x-Features wie Vector Sets für KI-Workloads will, bleibt bei Redis.

Dieser Guide zeigt dir den kompletten Weg: von der RAM-Dimensionierung über Installation, Härtung und Kernel-Tuning bis zu Cache-Strategien, Monitoring und Kostenvergleich. Alle Befehle sind für Ubuntu 24.04 LTS und Debian 13 getestet.

VPS-Dimensionierung: Wie viel RAM braucht Redis wirklich?

Redis hält alle Daten im RAM. Es gibt kein Swap-Fallback, das nicht sofort in einen Latenz-Tod führt – sobald der Kernel Redis-Seiten auf Disk swappt, bricht die Performance um den Faktor 100 ein. Die Faustregel lautet daher: maxmemory = 70 bis 75 % des verfügbaren VPS-RAM, der Rest bleibt für Betriebssystem, Anwendung und Copy-on-Write-Fork beim Snapshot.

Die zweite Frage ist der Overhead. Redis speichert nicht nur die reinen Werte, sondern pro Key rund 50–90 Byte Overhead für das Dict-Entry, das SDS-Header und die Expiry-Struktur. Ein 200 Byte großer JSON-Value belegt real also etwa 270–300 Byte. Plane deshalb pauschal 30 % Aufschlag auf deine Nutzdatenmenge ein.

VPS-GrößeEmpfohlenes maxmemoryRealistische Cache-GrößeEinsatzszenarioPreis/Monat (Beispiel)
1 vCPU / 2 GB1,3 GB~900 MBSingle-Site WordPress, kleine API3,49–4,50 €
2 vCPU / 4 GB2,8 GB~2 GBWordPress Multisite, Laravel-App3,79–7,00 €
4 vCPU / 8 GB6 GB~4,3 GBMehrere Apps, Sessions, Rate-Limits6,80–14,00 €
8 vCPU / 16 GB12 GB~8,5 GBHigh-Traffic-API, Redis + App auf einem Host16,40–28,00 €
16 vCPU / 32 GB24 GB~17 GBRedis dediziert, mehrere Replicas32,00–55,00 €

Zum Vergleich: Ein Managed-Redis mit 1 GB RAM kostet bei den großen Cloud-Anbietern 2026 typischerweise 18–25 € pro Monat, ein 4-GB-Instance rund 60–80 €. Ein eigener VPS mit 8 GB RAM, auf dem Redis und die Anwendung gemeinsam laufen, liegt bei 7–14 € – also bei einem Fünftel. Der Preis dafür ist Eigenverantwortung für Backups, Monitoring und Updates.

Wichtig: Läuft Redis auf demselben Host wie die Anwendung, konkurrieren beide um RAM. In dem Fall setzt du maxmemory konservativer, etwa auf 50 % des Gesamt-RAM, und beobachtest regelmäßig die Speicherfragmentierung mit redis-cli INFO memory. Ein mem_fragmentation_ratio über 1,5 deutet auf ein Problem hin.

Installation: Redis 8 auf Ubuntu 24.04 und Debian 13

Ubuntu 24.04 LTS liefert in den Repositories Redis 7.0.15, Debian 13 „Trixie" bringt Redis 8.0 mit. Für die meisten Cache-Setups reicht die Distributionsversion völlig aus. Willst du die aktuelle 8.2er-Version mit Vector Sets und verbessertem IO-Threading, nutzt du das offizielle APT-Repository.

# Variante A: Distributionspaket (schnell, stabil)
sudo apt update
sudo apt install -y redis-server
systemctl status redis-server

# Variante B: Offizielles Redis-Repo für 8.x
sudo apt install -y curl gpg lsb-release
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

# Variante C: Valkey (Drop-in-Ersatz, BSD-Lizenz)
sudo apt install -y valkey

Nach der Installation prüfst du mit redis-server --version die Version und mit redis-cli PING, ob der Dienst antwortet. Erwartete Ausgabe: PONG. Läuft der Server nicht, zeigt journalctl -u redis-server -n 50 --no-pager die Ursache – meist ein Syntaxfehler in der Config oder ein belegter Port.

Für die weitere Arbeit empfehlen wir dringend, den redis-cli über den Unix-Socket statt über TCP zu nutzen. Das spart den Netzwerkstack komplett und reduziert die Latenz um weitere 20–30 %. Aktiviere dazu in der Config unixsocket /run/redis/redis.sock und unixsocketperm 770, danach verbindest du dich mit redis-cli -s /run/redis/redis.sock.

Wenn du Redis nur als Cache für eine lokale Anwendung betreibst, kannst du den Dienst auch per Socket-Activation oder als User-Service starten. Für den Produktivbetrieb bleibt aber das systemd-Service-File die sauberste Variante, weil es Restart-Policies, Limits und Logging zentral verwaltet.

Die wichtigsten redis.conf-Parameter für den Cache-Betrieb

Die Standardkonfiguration ist auf Persistenz und Datensicherheit optimiert, nicht auf reinen Cache-Betrieb. Für einen Cache kannst du aggressiv abspecken. Die folgende Konfiguration ist ein bewährter Ausgangspunkt für einen 8-GB-VPS:

# /etc/redis/redis.conf – Cache-Profil
bind 127.0.0.1 ::1
protected-mode yes
port 6379
unixsocket /run/redis/redis.sock
unixsocketperm 770

maxmemory 6gb
maxmemory-policy allkeys-lru
maxmemory-samples 10

# Kein Blockieren durch Freigabe großer Objekte
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
lazyfree-lazy-user-del yes

# Defragmentierung bei Fragmentierung aktivieren
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100
active-defrag-cycle-min 5
active-defrag-cycle-max 75

# Netzwerk
tcp-backlog 4096
tcp-keepalive 300
timeout 0
maxclients 10000

# IO-Threads nur bei >= 4 Kernen sinnvoll
io-threads 4
io-threads-do-reads yes

# Logging
loglevel notice
slowlog-log-slower-than 10000
slowlog-max-len 256

Die Wahl der Eviction-Policy ist entscheidend. allkeys-lru ist für reine Caches die richtige Wahl: Wenn der Speicher voll ist, wirft Redis die am längsten nicht genutzten Keys raus – egal ob sie ein TTL haben oder nicht. volatile-lru löscht nur Keys mit gesetztem TTL und liefert bei Speicherdruck Fehler für alles andere. Sobald du Redis auch für persistente Daten wie Sessions ohne TTL nutzt, ist volatile-lru sicherer, aber du musst dann konsequent alle Cache-Keys mit TTL versehen.

maxmemory-samples 10 erhöht die Genauigkeit des LRU-Algorithmus von den standardmäßigen 5 Samples auf 10. Das kostet minimal CPU, verbessert die Trefferquote aber messbar um 2–5 Prozentpunkte – bei 4 GB Cache sind das rund 100–200 MB mehr effektiv nutzbare Daten.

Die lazyfree-Optionen sind bei großen Values (über 100 KB) essenziell. Ohne sie blockiert Redis beim Löschen eines 5-MB-Objekts für mehrere Millisekunden, was sich als Latenz-Spike in allen anderen Requests bemerkbar macht. Mit aktiviertem Lazy-Free läuft die Freigabe in einem Background-Thread.

Sicherheit: Redis niemals offen ins Internet

Redis ist ohne Passwort und ohne Firewall ein offenes Scheunentor. Der berüchtigte Fall aus 2024, bei dem über 12.000 ungeschützte Redis-Instanzen zu Kryptomining-Bots kompromittiert wurden, ist kein Einzelfall – automatisierte Scanner finden eine offene Instanz auf Port 6379 innerhalb von 2 bis 8 Stunden. Die Mindestabsicherung besteht aus vier Maßnahmen.

  1. Bind auf Loopback: bind 127.0.0.1 ::1 – ohne diese Zeile lauscht Redis auf allen Interfaces.
  2. Protected Mode: protected-mode yes verhindert Zugriffe von außen, wenn kein Passwort gesetzt ist.
  3. Firewall: sudo ufw allow from 10.0.0.0/24 to any port 6379 – falls externe Clients nötig sind, nur aus dem privaten Netz.
  4. Authentifizierung: requirepass mit mindestens 48 Zeichen oder besser ACLs.

Für Mehrbenutzer-Setups sind ACLs seit Redis 6 die saubere Lösung. Du definierst einen eingeschränkten User, der nur auf einen Key-Namespace zugreifen darf:

# In redis.conf oder per redis-cli ACL SETUSER
user appuser on >S3hrLangesPasswort2026! ~cache:* +get +set +del +expire +ttl +info resetchannels -@all

# Prüfen
ACL LIST
ACL WHOAMI

Der Präfix ~cache:* beschränkt den User auf Keys, die mit cache: beginnen. -@all entfernt alle Rechte, danach werden nur die explizit erlaubten Befehle wieder hinzugefügt. So kann selbst ein kompromittierter Anwendungsserver keine FLUSHALL- oder CONFIG SET-Befehle absetzen. Das CONFIG-Kommando lässt sich zusätzlich per rename-command CONFIG "" komplett deaktivieren – dann ist allerdings auch kein Live-Tuning mehr möglich.

Wenn Clients über ein unsicheres Netzwerk zugreifen, solltest du TLS aktivieren. Redis 8 unterstützt TLS nativ: tls-port 6380, tls-cert-file, tls-key-file, tls-ca-cert-file und tls-auth-clients yes. Der Overhead liegt bei etwa 5–12 % Durchsatz, was für die meisten Anwendungen akzeptabel ist. Alternativ kapselst du den Verkehr per WireGuard oder SSH-Tunnel – das ist oft einfacher und schneller.

Kernel- und System-Tuning für minimale Latenz

Redis läuft im Userspace, ist aber extrem empfindlich gegenüber Kernel-Einstellungen. Drei Parameter solltest du auf jedem VPS setzen, der Redis hostet.

# /etc/sysctl.d/99-redis.conf
vm.overcommit_memory = 1
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 4096

# Anwenden
sudo sysctl --system

vm.overcommit_memory = 1 ist der wichtigste Wert. Ohne ihn kann der fork()-Aufruf für einen Background-Save fehlschlagen, wenn der Speicher knapp ist, und du bekommst die berüchtigte Warnung „Background save may fail under low memory condition". Mit Overcommit erlaubt der Kernel die Speicherzusage, auch wenn sie theoretisch nicht gedeckt ist – bei Copy-on-Write-Snapshots ist das korrekt und sicher.

Transparent Huge Pages (THP) müssen deaktiviert werden. THP führt bei Redis zu Latenz-Spikes von 20–80 ms, weil der Kernel Speicherseiten asynchron zusammenlegt und dabei den Redis-Event-Loop blockiert. Deaktiviere THP dauerhaft über eine systemd-Unit:

# /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages
Before=redis-server.service
DefaultDependencies=no
After=sysinit.target local-fs.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'

[Install]
WantedBy=basic.target

Danach sudo systemctl daemon-reload und sudo systemctl enable --now disable-thp.service. Prüfen kannst du das mit cat /sys/kernel/mm/transparent_hugepage/enabled – die Ausgabe muss [never] in eckigen Klammern zeigen.

Als drittes erhöhst du das File-Descriptor-Limit. Der Standard von 1024 ist für 10.000 gleichzeitige Verbindungen zu niedrig. Lege ein systemd-Override an:

sudo mkdir -p /etc/systemd/system/redis-server.service.d
cat <<'EOF' | sudo tee /etc/systemd/system/redis-server.service.d/override.conf
[Service]
LimitNOFILE=65535
LimitMEMLOCK=infinity
OOMScoreAdjust=-900
EOF
sudo systemctl daemon-reload
sudo systemctl restart redis-server

OOMScoreAdjust=-900 macht Redis für den Linux-OOM-Killer praktisch unantastbar. Das ist bewusst so gewählt: Wenn der Speicher knapp wird, soll lieber ein Anwendungsprozess sterben als der Cache – ein Neustart von Redis bedeutet einen komplett kalten Cache und eine massive Lastspitze auf der Datenbank.

Persistenz: RDB, AOF oder gar nichts?

Für einen reinen Cache ist die Antwort eindeutig: keine Persistenz. Wenn Redis neu startet, ist der Cache kalt, die Anwendung füllt ihn in wenigen Sekunden bis Minuten wieder. Du sparst dir damit Fork-Latenzen, Disk-I/O und die häufigste Fehlerquelle überhaupt.

# Reiner Cache-Modus
save ""
appendonly no

Die save ""-Direktive deaktiviert alle RDB-Snapshots, appendonly no schaltet das Append-Only-File ab. Achte darauf, dass du nicht versehentlich eine der save 900 1-Zeilen aus der Default-Config stehen lässt – die Zeile save "" muss die anderen überschreiben, deshalb am besten alle save-Zeilen auskommentieren und nur save "" setzen.

Wenn du Redis auch als Session-Store nutzt, brauchst du zumindest eine minimale Persistenz. Die pragmatische Lösung ist RDB mit langen Intervallen:

save 900 1
save 300 100
dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error no

stop-writes-on-bgsave-error no ist im Cache-Betrieb wichtig: Wenn die Disk voll ist und der Snapshot fehlschlägt, soll Redis trotzdem weiter bedienen, statt alle Schreibvorgänge zu verweigern. Genau diese Einstellung verhindert die klassische Fehlermeldung „MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk".

AOF ist für Cache-Workloads meist Overkill. appendfsync everysec kostet 10–20 % Durchsatz, always kostet bis zu 60 % und bringt nur bei echten Datenbank-Anwendungsfällen etwas. Wenn du AOF nutzt, aktiviere unbedingt aof-use-rdb-preamble yes und auto-aof-rewrite-percentage 100 mit auto-aof-rewrite-min-size 256mb, sonst wächst das Log unkontrolliert.

Cache-Strategien, TTL-Design und Key-Naming

Die häufigste Ursache für schlechte Cache-Performance ist nicht Redis, sondern das Design der Anwendungsschicht. Drei Muster haben sich bewährt.

Cache-Aside ist der Standard: Lesen aus dem Cache, bei Miss aus der DB lesen und in Redis schreiben. Der Vorteil ist die einfache Fehlerbehandlung – fällt Redis aus, funktioniert die Anwendung weiter, nur langsamer. Genau deshalb sollte jeder Redis-Aufruf in der Anwendung in einem Try-Catch mit Fallback auf die Datenbank stehen.

Write-Through schreibt bei jeder Änderung sofort in Cache und DB. Das hält den Cache konsistent, kostet aber Schreiblast. Für häufig gelesene, selten geänderte Daten (Produktkataloge, Konfigurationen) ist das ideal.

Probabilistic Early Expiration löst das Cache-Stampede-Problem: Statt dass bei Ablauf eines populären Keys 500 gleichzeitige Requests alle in die Datenbank laufen, berechnet jeder Client eine Zufallsschwelle und erneuert den Key leicht vor Ablauf. In Redis lässt sich das mit einem Lock absichern:

SET cache:report:42 <value> EX 300
# Stampede-Schutz beim Neubau
SET lock:report:42 1 NX PX 5000
# Nur wer das Lock bekommt, baut den Cache neu

Beim TTL-Design gilt: Niemals alle Keys mit derselben TTL anlegen. Wenn 50.000 Keys gleichzeitig ablaufen, entsteht ein Lastberg. Streue die TTL mit einem Jitter von ±10 %:

ttl = base_ttl + random(-0.1 * base_ttl, +0.1 * base_ttl)

Beim Key-Naming hat sich ein hierarchisches Schema mit Versionspräfix durchgesetzt: app:v2:user:1234:profile. Der Versionsbestandteil erlaubt dir, nach einem Deployment alle alten Keys durch Hochzählen der Version zu invalidieren, ohne KEYS oder SCAN über Millionen Einträge laufen zu lassen. Verwende niemals KEYS * in Produktion – der Befehl blockiert den Event-Loop bei 1 Million Keys für 1–3 Sekunden. Nutze stattdessen SCAN 0 MATCH app:v2:* COUNT 1000 in einer Schleife.

Anbindung an WordPress, Laravel, Node.js und Sessions

Für WordPress ist der Weg über das Plugin „Redis Object Cache" der Standard. Du installierst php-redis (phpredis, nicht Predis – die C-Extension ist 3–5× schneller), trägst in der wp-config.php ein:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'deinPasswort');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
define('WP_REDIS_MAXTTL', 86400);

Der WP_REDIS_MAXTTL-Wert von 86400 Sekunden (24 h) verhindert, dass Objekte ewig im Cache liegen. Danach aktivierst du das Plugin im Backend und prüfst den Status. Typisches Ergebnis: Die Query-Zeit einer WooCommerce-Produktseite sinkt von 320 ms auf 45 ms, die Zahl der DB-Queries von 87 auf 6.

Bei Laravel setzt du in der .env: CACHE_STORE=redis, REDIS_HOST=127.0.0.1, REDIS_CLIENT=phpredis und optional REDIS_CACHE_DB=1, um Cache und Session zu trennen. Der Artisan-Befehl php artisan cache:clear nutzt dann automatisch Redis. Für Sessions setzt du SESSION_DRIVER=redis – das ist besonders bei mehreren App-Servern hinter einem Loadbalancer Pflicht.

In Node.js ist ioredis die robustere Wahl gegenüber node-redis, weil es Auto-Reconnect, Cluster-Support und Pipeline-Batching out of the box mitbringt. Ein minimales Setup mit Connection-Pooling:

const Redis = require('ioredis');
const redis = new Redis({
  host: '127.0.0.1',
  port: 6379,
  password: process.env.REDIS_PASS,
  maxRetriesPerRequest: 2,
  enableOfflineQueue: false,
  connectTimeout: 1000
});

async function cached(key, ttl, loader) {
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit);
  const value = await loader();
  await redis.set(key, JSON.stringify(value), 'EX', ttl);
  return value;
}

enableOfflineQueue: false ist im Cache-Betrieb entscheidend: Wenn Redis nicht erreichbar ist, sollen Requests sofort fehlschlagen und die Anwendung auf die DB zurückfallen, statt in einer Warteschlange zu hängen und den Event-Loop zu blockieren.

Für PHP-Sessions über Redis setzt du in der php.ini: session.save_handler = redis und session.save_path = "tcp://127.0.0.1:6379?auth=deinPasswort&database=2". Bei mehreren Webservern ist das die einfachste Lösung für gemeinsame Sessions, ohne Sticky Sessions im Loadbalancer konfigurieren zu müssen.

Monitoring, Benchmarking und Troubleshooting

Bevor du optimierst, musst du messen. Die wichtigsten Befehle für den Alltag:

# Live-Statistik: Ops/s, Clients, Memory, Hit-Rate
redis-cli --stat

# Latenz über 60 Sekunden messen (Angaben in ms)
redis-cli --latency -h 127.0.0.1

# Intrinsische System-Latenz (Baseline ohne Redis)
redis-cli --intrinsic-latency 100

# Hit-Rate berechnen
redis-cli INFO stats | grep keyspace

# Die 10 langsamsten Befehle
redis-cli SLOWLOG GET 10

# Speicheranalyse
redis-cli INFO memory
redis-cli --bigkeys
redis-cli --memkeys

# Latenz-Diagnose mit Empfehlungen
redis-cli LATENCY DOCTOR

Die Hit-Rate ist die wichtigste Kennzahl. Sie berechnet sich aus keyspace_hits / (keyspace_hits + keyspace_misses). Alles unter 80 % deutet auf ein TTL- oder Key-Design-Problem hin, 90–95 % ist für Web-Caches realistisch, über 97 % ist exzellent. Eine niedrige Hit-Rate bei gleichzeitig hohem evicted_keys-Wert bedeutet: Der Cache ist zu klein. Dann hilft entweder mehr RAM oder eine kürzere TTL für selten genutzte Daten.

Für das Benchmarking nutzt du redis-benchmark mit Pipelining, weil das dem realen Verhalten von Anwendungen näher kommt als Einzelrequests:

# 100.000 Requests, 50 parallele Clients, 16-fach gepipelined
redis-benchmark -h 127.0.0.1 -q -n 100000 -c 50 -P 16 -t set,get -d 256

# Typische Werte auf einem 4-vCPU-VPS (AMD EPYC):
# SET: 512.000 requests per second
# GET: 587.000 requests per second
# Ohne Pipelining (-P 1): ca. 95.000 ops/s

Bei den drei häufigsten Fehlerbildern hilft Folgendes. Latenz-Spikes über 10 ms: fast immer Transparent Huge Pages oder ein blockierender KEYS-/FLUSHALL-Aufruf – prüfe redis-cli LATENCY DOCTOR. Redis wird vom OOM-Killer beendet: maxmemory ist zu hoch gesetzt oder eine Anwendung leckt Speicher – setze OOMScoreAdjust=-900 und reduziere maxmemory um 20 %. Verbindungsabbrüche unter Last: net.core.somaxconn und tcp-backlog zu niedrig, oder das maxclients-Limit ist erreicht (redis-cli INFO clients).

Für dauerhaftes Monitoring empfehlen wir den oliver006/redis_exporter plus Prometheus und Grafana. Die vier wichtigsten Alert-Regeln: Hit-Rate unter 80 % für 15 Minuten, evicted_keys steigt um mehr als 1000/Minute, used_memory über 90 % von maxmemory, und connected_clients über 80 % von maxclients.

Redis vs. Valkey vs. Memcached vs. Dragonfly 2026

Die Auswahl ist 2026 größer als noch vor drei Jahren. Die folgende Tabelle fasst die wichtigsten Unterschiede für den VPS-Cache-Einsatz zusammen.

SystemLizenzPerformance (1 Thread)PersistenzBesonderheitEmpfehlung
Redis 8.2AGPLv3 / RSALv2~110.000 ops/sRDB, AOFVector Sets, Module, größtes ÖkosystemStandard für die meisten Setups
Valkey 9.0BSD-3~115.000 ops/sRDB, AOFLinux Foundation, Drop-in-ErsatzWer BSD-Lizenz braucht
Memcached 1.6BSD-3~180.000 ops/skeineMultithreaded, extrem einfachReiner Key-Value-Cache ohne Features
Dragonfly 1.xBSL 1.1~1.000.000 ops/sRDB, AOFMulti-Threaded, Redis-kompatibelSehr große Datasets, viele Kerne
KeyDB 6.xBSD-3~450.000 ops/sRDB, AOFMultithreaded ForkWartung 2026 unklar, eher meiden

Für 90 % aller VPS-Cache-Setups ist die Entscheidung einfach: Redis oder Valkey. Beide sind single-threaded im Command-Processing, was bei einem 4-vCPU-VPS bedeutet, dass du die CPU nie ausschöpfst – der Flaschenhals ist praktisch immer das Netzwerk oder die Anwendung, nicht Redis. Memcached ist bei reinem Key-Value-Caching etwa 60 % schneller, kann aber keine Datenstrukturen wie Sets, Sorted Sets oder Hashes, was Rate-Limiting und Leaderboards unmöglich macht.

Dragonfly ist interessant, wenn du mehr als 32 GB Cache und mindestens 8 Kerne hast. Auf einem 4-GB-VPS bringt der Multi-Threading-Vorteil nichts, weil du ohnehin nicht an das Limit von Redis stößt. Der Betrieb ist zudem komplexer und die BSL-Lizenz schließt kommerzielle Konkurrenzprodukte aus.

Ein wichtiger Hinweis zur Migration: Redis und Valkey sind auf Protokollebene kompatibel, du kannst also jederzeit wechseln, indem du das Paket tauschst und die Config übernimmst. Ein laufender Datenbestand lässt sich per MIGRATE oder durch simples Neubefüllen des Caches übertragen – bei einem reinen Cache ist der zweite Weg in 99 % der Fälle der einfachere.

Typische Fehler und eine Checkliste für den Produktivbetrieb

Die häufigsten Fehler, die wir in Redis-Setups auf VPS sehen, sind nicht exotisch, sondern immer dieselben fünf.

Die Produktiv-Checkliste in Kurzform: maxmemory auf 70 % des RAM gesetzt, allkeys-lru aktiv, bind 127.0.0.1, requirepass oder ACL aktiv, THP deaktiviert, vm.overcommit_memory=1, LimitNOFILE=65535, OOMScoreAdjust=-900, Lazy-Free aktiviert, Persistenz für reine Caches aus, Monitoring mit Hit-Rate-Alert, und ein dokumentierter Fallback in der Anwendung für den Fall, dass Redis nicht erreichbar ist.

Wenn du diese Punkte abarbeitest, hast du ein Setup, das auf einem 7-Euro-VPS mehr Caching-Leistung liefert als ein Managed-Service für 80 Euro im Monat. Der Aufwand liegt bei etwa 45 bis 90 Minuten für die Ersteinrichtung – und zahlt sich bei jeder einzelnen Seitenauslieferung zurück.

FAQ

Wie viel RAM sollte ich Redis auf einem VPS geben?

Setze maxmemory auf 70 bis 75 % des verfügbaren VPS-RAM. Auf einem 4-GB-VPS also 2,8 GB, auf einem 8-GB-VPS 6 GB. Der Rest wird für Betriebssystem, Anwendung und Copy-on-Write-Fork benötigt. Rechne zusätzlich 30 % Overhead auf deine Nutzdatenmenge, weil Redis pro Key 50–90 Byte Metadaten speichert.

Ist Redis ohne Passwort sicher, wenn es nur auf 127.0.0.1 lauscht?

Für einen einzelnen Host mit ausschließlich lokalen Clients ist bind 127.0.0.1 plus protected-mode yes eine akzeptable Basisabsicherung. Sobald aber Container, andere Hosts im Netz oder mehrere Anwendungen mit unterschiedlichen Rechten zugreifen, brauchst du zwingend ein Passwort oder ACLs. Automatisierte Scanner finden offene Redis-Instanzen auf öffentlichen IPs innerhalb von 2 bis 8 Stunden.

Sollte ich für einen reinen Cache RDB oder AOF aktivieren?

Nein. Für einen reinen Cache deaktivierst du beides mit save "" und appendonly no. Der Cache füllt sich nach einem Neustart in Sekunden bis Minuten neu. Nur wenn du Redis auch als Session-Store oder für persistente Daten nutzt, brauchst du mindestens RDB mit langen Intervallen und stop-writes-on-bgsave-error no.

Redis oder Valkey – was soll ich 2026 nehmen?

Für reines Caching sind beide funktional identisch und protokollkompatibel. Nimm Valkey, wenn du eine reine BSD-Lizenz brauchst oder deine Distribution es bereits als Standard mitbringt (Debian 13, Fedora 41+). Nimm Redis 8.x, wenn du Features wie Vector Sets, RedisJSON oder das größere Modul-Ökosystem nutzt. Ein Wechsel zwischen beiden ist jederzeit durch Pakettauch und Config-Übernahme möglich.

Wie erkenne ich, dass mein Redis-Cache zu klein ist?

Zwei Kennzahlen verraten es: evicted_keys steigt kontinuierlich (sichtbar in redis-cli INFO stats), und die Hit-Rate fällt unter 85 %. Beides zusammen bedeutet, dass Redis ständig Keys verdrängt, bevor sie wiederverwendet werden. Lösungen in dieser Reihenfolge: TTL für selten genutzte Daten verkürzen, große Values komprimieren (gzip vor dem SET), mehr RAM zuweisen, oder auf mehrere Redis-Instanzen pro Anwendungsbereich aufteilen.

Kann ich Redis auf demselben VPS wie die Datenbank laufen lassen?

Ja, aber mit Einschränkungen. Redis und MySQL/PostgreSQL konkurrieren um RAM und Disk-I/O. Auf einem 8-GB-VPS mit beiden Diensten setzt du maxmemory für Redis auf maximal 3 GB und für MySQL den innodb_buffer_pool_size auf 2 GB. Achte darauf, dass Redis keine RDB-Snapshots schreibt, wenn die Datenbank gerade eine große Query verarbeitet – das führt zu I/O-Spikes und Latenz-Ausreißern bei beiden Systemen.

📖 Ähnliche Artikel