redis-benchmark: richtig nutzen und die Zahlen lesen

redis-benchmark ist das Benchmark-Werkzeug, das mit Redis ausgeliefert wird: Es öffnet eine Anzahl von Client-Verbindungen (standardmäßig 50), sendet eine feste Zahl von Befehlen (standardmäßig 100.000) und meldet für jeden Test Anfragen pro Sekunde und Latenz. Starten Sie redis-benchmark -q -n 100000 gegen einen laufenden Server, grenzen Sie mit -t auf die Befehle ein, die Sie interessieren, und lesen Sie das Ergebnis als Geschwindigkeit einer einzelnen Redis-Instanz unter synthetischen Befehlen. Ihre Anwendung bringt einen eigenen Netzwerkweg, eine eigene Client-Bibliothek und einen eigenen Befehlsmix mit; rechnen Sie also mit anderen Werten.

Wir haben es am 31. Oktober 2026 auf einem Apple-M1-Max-Laptop ausgeführt, Redis 7.2.6 als Server und Client auf derselben Maschine über Loopback, ohne Persistenz. Jede Zeile ist ein Lauf mit 100.000 Anfragen, die Anfragen pro Sekunde auf Tausend gerundet; p50 steht so da, wie das Tool es ausgab.

Wie führen Sie redis-benchmark aus?

Richten Sie das Tool mit -h und -p auf einen laufenden Server; ohne Optionen läuft die Standard-Testreihe gegen 127.0.0.1:6379. Mit -t wählen Sie Tests aus, mit -q erhalten Sie eine Zeile pro Test.

redis-benchmark -h 10.0.0.12 -p 6379 -c 50 -n 100000 \
  -t set,get -q

Die offizielle Redis-Benchmark-Seite und die --help-Ausgabe von Version 7.2.6 nennen unter anderem diese Optionen (geprüft am 31. Oktober 2026):

• -c parallele Verbindungen (Standard 50) und -n Anfragen insgesamt (Standard 100.000).
• -d Größe der SET- und GET-Werte in Byte (Standard 3).
• -P Befehle pro Pipeline (Standard 1, kein Pipelining).
• -t eine kommagetrennte Liste von Tests; -q knappe Ausgabe; --csv CSV-Ausgabe.
• -r zufällige Schlüssel aus einem Schlüsselraum dieser Größe. Ohne die Option nutzt jeder Befehl denselben Schlüssel.
• -k 1 hält Verbindungen offen (Standard), -k 0 verbindet neu.
• --threads schaltet den Multithread-Modus ein, --cluster den Cluster-Modus, in dem -c mindestens der Zahl der Knoten entsprechen muss.

Wie lesen Sie die Ausgabe von redis-benchmark?

Mit -q erhalten Sie pro Test eine Zeile: Anfragen pro Sekunde und die Median-Latenz. Ohne -q gibt jeder Test seine Einstellungen aus, eine Latenzverteilung nach Perzentilen und eine Zusammenfassung mit Durchschnitt, Minimum, p50, p95, p99 und Maximum.

Der Kopf zeigt außerdem die Server-Einstellungen save und appendonly, an denen Sie sehen, ob Persistenz Teil des Tests war. Unser vollständiger GET-Lauf ergab 119.617 Anfragen pro Sekunde, im Schnitt 0,352 ms, p95 0,559 ms, p99 0,623 ms und maximal 0,759 ms. Eine Anfrage, die Redis viele Male aufruft, trifft eher auf einen langsamen Aufruf, also lesen Sie auch p99; mehr dazu im Artikel über Tail-Latenz.

--csv gibt die Zusammenfassung als eine Zeile pro Test aus. Wiederholen Sie Läufe, bevor Sie einem kleinen Unterschied trauen: Zwei Läufe desselben SET-Tests ergaben bei uns etwa 113.000 und 125.000 Anfragen pro Sekunde.

Warum verändert Pipelining die Zahlen so stark?

Ohne -P wartet jeder Client auf eine Antwort, bevor er den nächsten Befehl sendet, sodass jeder Befehl einen vollen Roundtrip kostet. Mit -P 16 sendet jeder Client 16 auf einmal, und in unserem Lauf stieg SET von etwa 113.000 auf 1.010.000 Anfragen pro Sekunde, GET von 118.000 auf 1.190.000.

Die offizielle Seite nennt Pipelining realistisch, weil viele Redis-Anwendungen es nutzen, und rät zu einer Pipeline-Größe nahe dem Durchschnitt, den Ihre Anwendung tatsächlich erreicht. Unsere Median-Latenz stieg dabei auf 0,711 und 0,583 ms.

Was passiert, wenn Sie mehr Clients hinzufügen?

Ist der Engpass ausgelastet, bringen mehr Clients nur mehr Wartezeit. Auf einem einzelnen Laptop kann das der Server oder der Benchmark-Client mit nur einem Thread sein.

Von 50 auf 200 Clients blieb der Durchsatz fast gleich (etwa 117.000 SET- und 123.000 GET-Anfragen pro Sekunde), während sich die Median-Latenz ungefähr verdreifachte, auf 1,135 und 1,071 ms. Das ist Little’s Law in Aktion. Jeder Client hat höchstens einen Befehl unterwegs, also legt -c fest, wie viele sich im System befinden, und wenn der Durchsatz nicht wachsen kann, muss die Zeit wachsen, die jeder dort verbringt. In unserem vollständigen GET-Lauf ergeben 50 Clients ÷ 119.617 Anfragen pro Sekunde 0,42 ms pro Client-Durchlauf, etwas mehr als der gemessene Durchschnitt von 0,352 ms. Mit 200 Clients ergibt dieselbe Rechnung 1,63 ms.

Damit folgt das Tool auch einem geschlossenen Lastmodell: Wenn Redis hängt, warten die Clients, und die Befehle, die Ihre Anwendung in der Zwischenzeit gesendet hätte, tauchen nie auf. Weder die offizielle Seite noch --help nennt eine Option für eine feste Anfragerate, lesen Sie die Perzentile also mit Blick auf Coordinated Omission.

Wie benchmarken Sie einen eigenen Befehl oder ein Lua-Skript?

Schreiben Sie den Befehl hinter die Optionen. Das Tool führt dann nur diesen Befehl aus und ignoriert -t.

redis-benchmark -n 100000 -q \
  script load "redis.call('set','foo','bar')"
redis-benchmark -r 10000 -n 10000 \
  eval 'return redis.call("ping")' 0

Die erste Zeile ist das Beispiel der offiziellen Seite; auf unserem Laptop lief es mit etwa 106.000 Anfragen pro Sekunde. SCRIPT LOAD lädt das Skript nur, also messen Sie mit eval wie in der zweiten Zeile aus --help, wie lange das Ausführen dauert. Mit -r wird laut Hilfe __rand_int__ in einem Argument durch eine zufällige zwölfstellige Zahl aus diesem Bereich ersetzt, und im Cluster-Modus muss der Schlüssel ein {tag} enthalten, damit der Befehl den richtigen Knoten erreicht.

Warum misst Ihre Anwendung andere Werte?

Ihre Anwendung misst ihren ganzen Weg zu Redis: Netzwerk, Client-Bibliothek, Serialisierung und ihren eigenen Befehlsmix. Die offizielle Seite nennt Fallstricke, die Sie vor einem Vergleich prüfen sollten.

• Eine Schleife synchroner Befehle misst vor allem das Netzwerk und die Client-Bibliothek.
• Laufen Client und Server auf einer Maschine, begrenzt die CPU den Benchmark. Unix Domain Sockets können auf manchen Plattformen, etwa Linux, rund 50 % mehr Durchsatz als TCP-Loopback erreichen.
• Strings mit 4 KB bei 100.000 Anfragen pro Sekunde brauchen etwa 3,2 Gbit/s, mehr als eine 1-Gbit/s-Leitung trägt.
• Für einen Vergleich mit einer transaktionalen Datenbank schalten Sie AOF ein und wählen eine passende fsync-Richtlinie.
• Laptops ändern ihre CPU-Frequenz, was die Wiederholbarkeit verschlechtert.
• INFO in regelmäßigen Abständen ist während eines Laufs wohl unproblematisch, MONITOR dagegen bremst Redis deutlich.

Zeigen diese Laptop-Zahlen die echte Kapazität von Redis?

Nein. Sie zeigen einen Laptop, der mit sich selbst spricht, ohne Netzwerk, meist mit Werten von 3 Byte, ohne Persistenz und mit einem Lauf pro Zeile.

Die Tabelle zeigt, wie jede Option die Werte verschiebt. Die Kapazität hängt von Ihrem Server, Ihrem Netzwerk, Ihren Wertgrößen und Ihren Persistenz-Einstellungen ab.

Wann ist redis-benchmark das falsche Werkzeug?

Wenn Sie wissen wollen, was Benutzer spüren. Es sendet synthetische Befehle nur an Redis, während die Antwortzeit einer Seite auch den Anwendungscode und dessen weitere Aufrufe enthält.

Dafür belasten Sie die Anwendung oder API, die Redis nutzt, und beobachten Redis währenddessen. LoadFocus, der Herausgeber dieser Website, arbeitet auf dieser Ebene und führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen Ihre Web-App oder API aus. LoadFocus führt redis-benchmark nicht aus.

Für mehr Kontrolle über den Redis-Traffic nennt das Repository von memtier_benchmark Multithread-Clients, ein Lese-Schreib-Verhältnis, zufällige oder sequenzielle Schlüsselmuster, Redis Cluster und TLS (geprüft am 31. Oktober 2026).

FAQ

Ist redis-benchmark dafür gebaut, Redis schnell aussehen zu lassen? Nein. Die offizielle Redis-Seite nennt das ein verbreitetes Missverständnis: Standardmäßig hat das Tool höchstens eine offene Anfrage pro Verbindung, ohne Pipelining, und ein Client mit Pipelining kann mehr Durchsatz erzeugen.

Wie füllen Sie eine Redis-Datenbank mit redis-benchmark? Führen Sie nur den SET-Test mit zufälligen Schlüsseln aus, wie die Hilfe des Tools zeigt: -t set -n 1000000 -r 100000000 füllt etwa eine Million Schlüssel. Zufällige Schlüssel können sich wiederholen, daher liegt die Endzahl etwas darunter.

Kann LoadFocus redis-benchmark ausführen? Nein. LoadFocus führt redis-benchmark nicht aus. Seine JMeter-Testpläne und k6-Skripte zielen auf die Web-App oder API vor Redis.

Weiterlesen

• Little’s Law im Lasttest: Tests dimensionieren und prüfen
• Tail-Latenz: was sie ist und wie man sie misst
• Coordinated Omission: was es ist und wie man es vermeidet
• Offenes vs geschlossenes Lastmodell: welches passt wann?
• HTTP-Benchmark-Tools: wrk, hey, oha, ab und weitere
• pgbench: PostgreSQL benchmarken und unter Last testen
• sysbench nutzen: CPU-, Festplatten- und MySQL-Benchmarks
• YCSB: Workloads A-F, Ausführung und Grenzen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.