Redis-Latenz-Benchmark: HotKV vs. Valkey und Dragonfly

Dieser Redis-Latenz-Benchmark misst, wie lange HotKV, Redis, Valkey und Dragonfly bei einer festen Anfragerate zum Antworten brauchen. Unsere früheren Benchmarks haben den Durchsatz gemessen, und ein Leser hat zu Recht darauf hingewiesen, dass der Durchsatz nicht alles ist. Deshalb haben wir die Last konstant gehalten, Schritt für Schritt erhöht und bei jedem Schritt den Median (p50) und das 99. Perzentil (p99) erfasst. Außerdem haben wir die Zustellzeit von Pub/Sub gemessen.

Kurz gesagt. In diesem Redis-Latenz-Benchmark auf AWS hielten HotKV und Dragonfly beide 1,6 Millionen GETs pro Sekunde, Redis mit 8 I/O-Threads etwa 0,8 Millionen, Valkey mit 8 I/O-Threads etwa 0,4 Millionen und Redis und Valkey mit einem Thread etwa 0,2 Millionen. Von 200.000 bis 1,6 Millionen Anfragen pro Sekunde blieb das p99 von HotKV zwischen 0,59 und 0,76 ms, bei Dragonfly zwischen 0,71 und 1,48 ms. Bei geringer Last lagen die Multithread-Produkte beim p99 gleichauf, und auch die Pub/Sub-Zustellung war ein Unentschieden.

Warum wir einen Redis-Latenz-Benchmark mit fester Rate durchgeführt haben

Ein Durchsatztest treibt einen Server so weit, wie er geht, und meldet, wie viel er bedient hat. Das sagt wenig darüber, wie lange eine einzelne Anfrage wartet. Ein Latenztest legt fest, wie viele Anfragen pro Sekunde die Clients senden, und misst die Zeit jeder einzelnen. Der Server steht dann unter derselben Last wie jedes andere Produkt, sodass sich die Zeiten vergleichen lassen.

Diese Art von Test hat einen Haken. memtier_benchmark arbeitet im geschlossenen Regelkreis, ein Client wartet also auf eine Antwort, bevor er die nächste Anfrage sendet. Kommt ein Server nicht mehr mit, sendet der Client einfach weniger Anfragen, und die Latenz der gesendeten sieht besser aus, als sie ist. Wir werten einen Schritt daher nur als gehalten, wenn die erreichte Rate mindestens 97 Prozent der angeforderten Rate beträgt. Schritte, die diesen Test nicht bestehen, sind in den Tabellen als „NS“ (nicht gehalten) markiert, und ihre Latenz wird nicht gezeigt.

Was wir getestet haben

Maschinen

• Server und Lastgenerator. Instanzen vom Typ c8a.12xlarge (AMD EPYC 9R45, 48 Kerne, kein SMT, 96 GiB, 22,5 Gbit/s Netzwerk) in einer AWS-Cluster-Placement-Group in eu-south-2a unter Ubuntu 24.04. Eine Instanz führte den Lastgenerator aus, eine den Server.
• Ein Produkt nach dem anderen. Jedes Produkt lief allein auf dem Server, sodass sich nichts überlagerte und nichts das Netzwerk teilte. Jeder Serverprozess war an die CPUs 0 bis 39 gebunden, bei ausgeschalteter Persistenz und ausgeschaltetem Protected Mode.

Produkte

• HotKV 0.3.0 mit 40 Threads.
• Dragonfly 2.0.2 mit 40 Proactor-Threads.
• Redis 8.10.3 und Valkey 9.1.3, jeweils zweimal gelaufen, einmal im Standard-Setup mit einem Thread und einmal mit --io-threads 8.

Die Startzeile und die Live-Ausgabe von CONFIG GET jedes Laufs sind bei seinen Ergebnissen gespeichert.

Last und Vorgehen

Der Datensatz bestand aus 1.000.000 Schlüsseln mit 256-Byte-Werten, die Pipeline-Tiefe war 1, jede Anfrage wartet also auf ihre eigene Antwort. Die Last war nur GET sowie ein Mix aus 1 Schreibzugriff auf 10 Lesezugriffe. Jeder Schritt lief 20 Sekunden, zweimal, und wir berichten den Mittelwert der beiden Läufe. memtier_benchmark nutzte ein Ratenlimit pro Verbindung und zeichnete ein HDR-Histogramm auf. Wir haben zwei Verbindungszahlen getestet.

• 816 Verbindungen (24 Threads mit je 34 Verbindungen), für Raten von 20.000 bis 2,4 Millionen Anfragen pro Sekunde.
• 48 Verbindungen (4 Threads mit je 12 Verbindungen), für Raten bis 300.000 Anfragen pro Sekunde. Darüber können 48 Verbindungen die Rate nicht erreichen, weil jede Verbindung nur so schnell senden kann, wie sie Antworten erhält.

Ergebnisse

Zuerst kommen die GET-Tabellen, eine für jede Verbindungszahl, danach Pub/Sub.

Bei 816 Verbindungen

Jede Zelle zeigt p50 / p99 in Millisekunden für GET. „NS“ steht für nicht gehalten, in Klammern steht die tatsächlich erreichte Rate. Ein Strich bedeutet, dass der Durchlauf für dieses Produkt bereits beendet war.

Die gemischte Last ergab dasselbe Bild. Das p99 von HotKV lag von 200.000 bis 1,6 Millionen Anfragen pro Sekunde bei 0,54 bis 0,75 ms, und die Punkte, die jedes Produkt halten konnte, waren dieselben wie bei GET. Alles steht im Ergebnisordner.

So sind die Zeilen mit einem Thread zu lesen

Die Mediane von 1,6 bis 3 ms bei Redis und Valkey mit einem Thread und 816 Verbindungen sind nicht ihre Latenz im stationären Betrieb. Mit einem Ratenlimit lässt memtier_benchmark alle 816 Verbindungen im selben Moment senden. Ein Server mit einem Thread muss diesen Schub von 816 Anfragen nacheinander abarbeiten, sodass der Median einer Anfrage ihren Platz in der Warteschlange enthält. Den Test mit 48 Verbindungen unten haben wir durchgeführt, um diesen Effekt zu beseitigen.

Bei 48 Verbindungen

Die Zellen haben dieselbe Bedeutung wie oben, nur für GET.

Zustellzeit bei Pub/Sub

Wir haben die Zeit von einem Publish bis zur Zustellung an einen Subscriber gemessen, mit 64 Publishern, 100 Subscribern und 128 Byte Nutzlast, mit pubsub-sub-bench. Jede Nachricht ging an einen Subscriber. Die Zellen zeigen p50 / p99 in Millisekunden.

Alle Produkte stellten im selben Bereich zu. Bei der höchsten Last hatten die Produkte mit einem Thread einen höheren Median, 0,51 und 0,57 ms gegenüber 0,11 ms bei HotKV.

Außerdem mussten wir pubsub-sub-bench patchen. Das Tool verglich eine Publish-Zeit in Millisekunden mit einer Empfangszeit in Mikrosekunden. Der Patch liegt im Ergebnisordner.

Was die Ergebnisse zeigen

Die Tabellen zeigen bei hoher Last einen Vorsprung für HotKV und Dragonfly, bei geringer Last ein Unentschieden und eine Obergrenze für Redis und Valkey mit einem Thread.

HotKV und Dragonfly hielten bis 1,6 Millionen Anfragen pro Sekunde ein niedriges Tail

Beide hielten bei 816 Verbindungen 1,6 Millionen GETs pro Sekunde, mit einem Median von 0,28 ms. Das p99 von HotKV lag ab 200.000 Anfragen pro Sekunde zwischen 0,59 und 0,76 ms. Bei Dragonfly lag es zwischen 0,71 und 1,48 ms, und bei 1,6 Millionen lagen beide nah beieinander (0,64 gegenüber 0,71 ms). Redis und Valkey mit I/O-Threads hielten die Rate bei niedrigeren Lasten nicht mehr, und Redis und Valkey mit einem Thread bei etwa 260.000.

Bei geringer Last liegen die Multithread-Produkte gleichauf

Bei 48 Verbindungen und bis zu 300.000 Anfragen pro Sekunde hatten HotKV, Dragonfly und Redis mit 8 I/O-Threads alle ein p99 von etwa 0,27 ms. HotKV hatte den niedrigsten Median, 0,08 bis 0,09 ms ab 100.000 Anfragen pro Sekunde, Dragonfly lag bei 0,08 bis 0,10 ms. Ein Unterschied von 0,01 ms liegt im Bereich dessen, was andere Teile des Aufbaus verursachen können, daher werten wir ihn nicht als Vorsprung.

Redis und Valkey mit einem Thread stießen bei etwa 230.000 pro Sekunde an ihre Grenze

Bei 48 Verbindungen hatten sie einen Median von etwa 0,2 ms und ein p99 von 0,35 bis 0,43 ms, und sie hielten 300.000 Anfragen pro Sekunde nicht (etwa 231.000 und 233.000). Das ist die Obergrenze eines Threads bei dieser Hardware und Last. Deshalb werden Redis und Valkey meist als viele Prozesse oder als Cluster betrieben, wie in unserem Cluster-Benchmark.

Grenzen

Dies sind Messungen von HotKV Ltd an den oben genannten Versionen und der oben genannten Konfiguration. Sie sind keine Aussage über andere Versionen, Konfigurationen oder Lasten dieser Produkte.

Der Testaufbau

• Ein Server, ein Lastgenerator. Zwei Wiederholungen pro Schritt, auf einem Satz Maschinen an einem Datum. Die Streuung zwischen Maschinen oder Tagen haben wir nicht gemessen.
• Von uns gewählte Setups. Redis und Valkey liefen im Standard-Setup mit einem Thread und mit --io-threads 8, und wir haben keines der Produkte darüber hinaus abgestimmt. Andere Einstellungen könnten ihre Werte verändern. Wenn Sie meinen, dass eine Einstellung hier ein Produkt benachteiligt, sagen Sie es uns, wir prüfen es und veröffentlichen das Ergebnis.
• Der Schub-Effekt des Tools. Bei 816 Verbindungen sind die Mediane der Produkte mit einem Thread durch die Funktionsweise des Ratenlimits von memtier_benchmark überhöht, wie oben erklärt.

Was nicht gemessen wurde

• Daten. Größere oder ungleich verteilte Werte, Speicher pro Schlüssel und Persistenz. Die Persistenz war bei allen Servern ausgeschaltet.
• Modi. Cluster-Modus, Sharded Pub/Sub, TLS, Replikation und Failover.
• Pub/Sub-Fan-out. Eine Nachricht an viele Subscriber.

Redis, Valkey und Dragonfly sind Marken ihrer jeweiligen Inhaber. Sie werden nur genannt, um die gemessene Software zu bezeichnen, und das impliziert weder Sponsoring noch Billigung oder Zugehörigkeit.

Selbst nachmessen

Die Sweep-Skripte, die Startzeile und die Live-Konfiguration jedes Servers, der Patch für pubsub-sub-bench und alle Rohergebnisse liegen im Benchmark-Repository. Das Latenz-Skript ist harness/lat_sweep.sh, das Pub/Sub-Skript ist harness/ps_sweep.sh. Der Ordner raw enthält pro Test ein Archiv mit dem JSON von memtier_benchmark, den HDR-Histogrammen und der CPU-Auslastung des Servers für jeden Lauf.

Selbst ausprobieren

HotKV Cloud betreibt HotKV für Sie. Starten Sie mit HotKV Cloud oder sprechen Sie mit dem Vertrieb, um HotKV mit Ihrer eigenen Last zu vergleichen.

Häufig gestellte Fragen