KeyDB: der multithreaded Fork von Redis

Bei Hosted Power möchten wir uns durch unsere Performance auszeichnen. Unser Ziel ist es, der schnellste und leistungsfähigste Anbieter auf dem Markt zu sein.

Daher ist Innovation in unserer Organisation unverzichtbar. So verbessern wir kontinuierlich unsere Prozesse und Tools, mit denen wir diese leistungsfähigen Umgebungen für Ihre Website(s) schaffen.

Hier kommt Redis ins Spiel: Dabei handelt es sich um einen In-Memory-Datenspeicher, der in unserer Umgebung für das Caching eingesetzt wird. Dadurch können wir Daten schnell abrufen, ohne auf die Festplatte zugreifen zu müssen, und minimale Antwortzeiten gewährleisten.

Lange Zeit drängte die Community Redis, das System multithreaded zu machen. Aus Gründen wie der einfacheren Programmierung und einer kosteneffizienten Bereitstellung entschied sich Redis jedoch, an seiner Single-Thread-Architektur festzuhalten.

Schließlich kamen multithreaded Alternativen zu diesem Caching-System auf, sodass auch professionelle Umgebungen begannen, diese Alternativen zu untersuchen und zu testen.

Als wir Benchmark-Ergebnisse von Alternativen sahen, die eine 5- bis 25-fache Performance gegenüber dem von Redis erwarteten Wert zeigten, begannen wir mit eigenen Tests. Eine Alternative erwies sich als besonders stabil und kompatibel für professionelle Umgebungen: KeyDB.

KeyDB-Logo

KeyDB ist ein multithreaded Fork von Redis. Das bedeutet, dass es vollständig mit dem Redis-Protokoll, dessen Änderungen und Modulen kompatibel ist und gleichzeitig verspricht, mit den zukünftigen Änderungen von Redis auf dem Upstream-Stand zu bleiben.

KeyDB ist nicht nur multithreaded, sondern bietet auch eine höhere Performance auf weniger Hardware, eine Verringerung der Clustergröße durch aktive Replikation (das bedeutet, dass 2 Master-Knoten sowohl Lese- als auch Schreibvorgänge akzeptieren), die Möglichkeit, mit ModJS eigene Befehle zu erstellen, sowie interessante kommende Funktionen wie FLASH-Speicher, JSON-Support und Multi-Tenant-Support. Das klingt vielversprechend. Dennoch müssen unsere eigenen Testergebnisse diese Erwartungen erst bestätigen.

Um die bestmöglichen Testergebnisse zu erzielen, verwendeten wir ein von RedisLabs entwickeltes und eingesetztes Benchmark-Tool namens memtier_benchmark. Damit lassen sich verschiedene Traffic-Muster gegen Redis-Instanzen erzeugen. So konnten wir unterschiedliche Szenarien mit variierender Clientanzahl und einer unterschiedlichen Anzahl von Anfragen dieser Clients in verschiedenen Setups nachbilden, von einem Setup mit 2XCPU und 4GB RAM bis zu einem Setup mit 8xCPU und 32GB RAM.

Die Ergebnisse enttäuschten nicht. Wir begannen die Tests in einer Umgebung mit lediglich 2 Kernen und 4GB RAM. Dabei verwendeten wir 100 Clients, die jeweils 100, 1000 und 10 000 Anfragen erzeugten.

Operationen pro Sekunde bei 2CPU und 4GB
KB pro Sekunde bei 2CPU und 4GB RAM

Wie die Ausgabe zeigt, ist Redis KeyDB deutlich überlegen und weist dabei eine niedrigere durchschnittliche Latenz auf.

Diese Ergebnisse waren zu erwarten, da sich die Performance von KeyDB mit der Zuweisung weiterer Threads deutlich verbessern sollte. Die Tests mit 4 Kernen stützen diese Hypothese bereits:

Operationen pro Sekunde bei 4CPU
KB pro Sekunde bei 4CPU und 8GB RAM

Ab 4 Kernen beginnt KeyDB, Redis bei allen Messwerten zu übertreffen. KeyDB führt 66% mehr Operationen pro Sekunde aus und erreicht einen höheren Datendurchsatz pro Sekunde, als Redis leisten kann. Wie erwartet, zeigten 6 Threads noch bessere Ergebnisse.

Operationen pro Sekunde bei 6CPU
KB pro Sekunde bei 6CPU

KeyDB verdoppelt den von Redis erzielbaren Datendurchsatz sowie die Anzahl der Operationen pro Sekunde. Hier zeigt sich ein klares Muster. Um dies zu bestätigen, erhöhten wir die Anzahl der Threads erneut auf 8.

Operationen pro Sekunde bei 8CPU
KB pro Sekunde bei 8CPU

Hier lassen sich Schlussfolgerungen ziehen: Vorteile zeigen sich ab einem Setup mit mindestens 4 Kernen, während der größte Durchsatz weiterhin mit einem Setup aus 6 Threads erzielt wird. Die Latenz ist in den obigen Diagrammen nicht als Messwert dargestellt, wurde jedoch in den Testergebnissen aufgeführt. Diese zeigen, dass KeyDB weiterhin eine niedrigere durchschnittliche Latenz aufweist.

Die Zukunft dieser Alternative ist vielversprechend. Da sie ein optimiertes Redis-Setup bereits übertrifft, wird die Suche nach Möglichkeiten, KeyDB in unsere Bereitstellung zu integrieren, eine kommende Funktion sein. Dadurch werden Websites auf unserem eigenen TurboStack® noch leistungsfähiger als zuvor.

Want to learn more about these topics?