Benchmark de latence Redis : HotKV face à Valkey et Dragonfly

Ce benchmark de latence Redis mesure le temps que mettent HotKV, Redis, Valkey et Dragonfly à répondre à un débit de requêtes fixe. Nos benchmarks précédents mesuraient le débit, et un lecteur a fait remarquer à juste titre que le débit ne fait pas tout. Nous avons donc gardé la charge constante, l’avons augmentée palier par palier, et relevé la médiane (p50) et le 99e centile (p99) à chaque palier. Nous avons aussi mesuré le temps de livraison du pub/sub.

En bref. Dans ce benchmark de latence Redis sur AWS, HotKV et Dragonfly ont tous deux tenu 1,6 million de GET par seconde, Redis avec 8 threads d’E/S environ 0,8 million, Valkey avec 8 threads d’E/S environ 0,4 million, et Redis et Valkey à un seul thread environ 0,2 million. De 200 000 à 1,6 million de requêtes par seconde, le p99 de HotKV est resté entre 0,59 et 0,76 ms, contre 0,71 à 1,48 ms pour Dragonfly. À faible charge, les produits multithreads sont à égalité sur le p99, et la livraison pub/sub aussi.

Pourquoi un benchmark de latence Redis à débit fixe

Un test de débit pousse un serveur aussi fort que possible et indique combien il a servi. Cela dit peu de choses sur le temps d’attente d’une requête. Un test de latence fixe le nombre de requêtes par seconde envoyées par les clients et mesure le temps de chacune. Le serveur est alors à la même charge que tout autre produit, et les temps peuvent être comparés.

Ce type de test a un piège. memtier_benchmark fonctionne en boucle fermée : un client attend une réponse avant d’envoyer la requête suivante. Si un serveur ne suit pas, le client envoie simplement moins de requêtes, et la latence de celles qu’il a envoyées paraît meilleure qu’elle ne l’est. Nous ne comptons donc un palier comme tenu que si le débit atteint est d’au moins 97 pour cent du débit demandé. Les paliers qui échouent sont marqués « NS » (non tenu) dans les tableaux et leur latence n’est pas affichée.

Ce que nous avons testé

Machines

• Serveurs et générateur de charge. Des instances c8a.12xlarge (AMD EPYC 9R45, 48 cœurs, sans SMT, 96 Gio, réseau de 22,5 Gbit/s) dans un groupe de placement de cluster AWS en eu-south-2a, sous Ubuntu 24.04. Une instance exécutait le générateur de charge et une autre le serveur.
• Un produit à la fois. Chaque produit a tourné seul sur le serveur, donc rien ne se chevauchait et rien ne partageait le réseau. Chaque processus serveur était épinglé sur les CPU 0 à 39, avec la persistance et le mode protégé désactivés.

Produits

• HotKV 0.3.0 avec 40 threads.
• Dragonfly 2.0.2 avec 40 threads proactor.
• Redis 8.10.3 et Valkey 9.1.3, chacun lancé deux fois, une fois avec la configuration par défaut à un seul thread et une fois avec --io-threads 8.

La ligne de lancement et la sortie en direct de CONFIG GET de chaque exécution sont enregistrées avec ses résultats.

Charge et procédure

Le jeu de données comptait 1 000 000 de clés avec des valeurs de 256 octets, et la profondeur de pipeline était de 1, chaque requête attend donc sa propre réponse. La charge était du GET seul, puis un mélange de 1 écriture pour 10 lectures. Chaque palier a duré 20 secondes, deux fois, et nous donnons la moyenne des deux exécutions. memtier_benchmark a utilisé une limite de débit par connexion et enregistré un histogramme HDR. Nous avons testé deux nombres de connexions.

• 816 connexions (24 threads de 34 connexions), pour des débits de 20 000 à 2,4 millions de requêtes par seconde.
• 48 connexions (4 threads de 12 connexions), pour des débits jusqu’à 300 000 requêtes par seconde. Au-delà, 48 connexions ne peuvent pas atteindre le débit, car chaque connexion ne peut envoyer qu’aussi vite qu’elle reçoit des réponses.

Résultats

Les tableaux GET viennent d’abord, un par nombre de connexions, puis le pub/sub.

Avec 816 connexions

Chaque cellule indique p50 / p99 en millisecondes, pour GET. « NS » signifie non tenu, et le débit réellement atteint figure entre parenthèses. Un tiret signifie que le balayage de ce produit s’était déjà arrêté.

La charge mixte a donné la même image. Le p99 de HotKV était de 0,54 à 0,75 ms de 200 000 à 1,6 million de requêtes par seconde, et les paliers que chaque produit pouvait tenir étaient les mêmes qu’avec GET. Tout figure dans le dossier de résultats.

Comment lire les lignes à un seul thread

Les médianes de 1,6 à 3 ms de Redis et Valkey à un seul thread avec 816 connexions ne sont pas leur latence en régime établi. Avec une limite de débit, memtier_benchmark fait partir les 816 connexions au même instant. Un serveur à un seul thread doit traiter cette rafale de 816 requêtes l’une après l’autre, si bien que la médiane d’une requête inclut sa place dans la file. Nous avons réalisé le test à 48 connexions ci-dessous pour supprimer cet effet.

Avec 48 connexions

Les cellules ont la même signification que ci-dessus, pour GET seulement.

Temps de livraison du pub/sub

Nous avons mesuré le temps entre une publication et sa livraison à un abonné, avec 64 éditeurs, 100 abonnés et une charge utile de 128 octets, à l’aide de pubsub-sub-bench. Chaque message allait à un seul abonné. Les cellules indiquent p50 / p99 en millisecondes.

Tous les produits ont livré dans la même plage. À la charge la plus élevée, les produits à un seul thread avaient une médiane plus haute, 0,51 et 0,57 ms contre 0,11 ms pour HotKV.

Nous avons aussi dû corriger pubsub-sub-bench. L’outil comparait un temps de publication en millisecondes à un temps de réception en microsecondes. Le correctif est dans le dossier de résultats.

Ce que montrent les résultats

Les tableaux montrent une avance de HotKV et Dragonfly à forte charge, une égalité à faible charge et un plafond pour Redis et Valkey à un seul thread.

HotKV et Dragonfly ont gardé une queue basse jusqu’à 1,6 million de requêtes par seconde

Tous deux ont tenu 1,6 million de GET par seconde à 816 connexions, avec une médiane de 0,28 ms. Le p99 de HotKV était compris entre 0,59 et 0,76 ms à partir de 200 000 requêtes par seconde. Celui de Dragonfly était compris entre 0,71 et 1,48 ms, et les deux étaient proches à 1,6 million (0,64 contre 0,71 ms). Redis et Valkey avec threads d’E/S ont cessé de tenir le débit à des charges plus basses, et Redis et Valkey à un seul thread vers 260 000.

À faible charge, les produits multithreads sont à égalité

Avec 48 connexions, jusqu’à 300 000 requêtes par seconde, HotKV, Dragonfly et Redis avec 8 threads d’E/S ont tous eu un p99 d’environ 0,27 ms. HotKV avait la médiane la plus basse, de 0,08 à 0,09 ms à partir de 100 000 requêtes par seconde, Dragonfly se situant entre 0,08 et 0,10 ms. Un écart de 0,01 ms reste dans ce que d’autres éléments du dispositif peuvent causer, nous n’en faisons donc pas une victoire.

Redis et Valkey à un seul thread ont atteint leur limite vers 230 000 par seconde

Avec 48 connexions, ils avaient une médiane d’environ 0,2 ms et un p99 de 0,35 à 0,43 ms, et n’ont pas tenu 300 000 requêtes par seconde (environ 231 000 et 233 000). C’est le plafond d’un seul thread sur ce matériel et cette charge. C’est pourquoi Redis et Valkey sont généralement exécutés en de nombreux processus ou en cluster, comme dans notre benchmark de cluster.

Limites

Ce sont des mesures de HotKV Ltd sur les versions et la configuration ci-dessus. Elles ne valent pas pour une autre version, une autre configuration ou une autre charge de ces produits.

Le dispositif de test

• Un serveur, un générateur de charge. Deux répétitions par palier, sur un seul jeu de machines à une seule date. Nous n’avons pas mesuré la variation entre machines ou entre jours.
• Configurations choisies par nous. Redis et Valkey ont tourné avec leur configuration par défaut à un seul thread et avec --io-threads 8, et nous n’avons réglé aucun des deux au-delà. D’autres réglages pourraient modifier leurs chiffres. Si vous pensez qu’un réglage ici désavantage un produit, dites-le-nous et nous le vérifierons et publierons le résultat.
• L’effet de rafale de l’outil. À 816 connexions, les médianes des produits à un seul thread sont gonflées par le fonctionnement de la limite de débit de memtier_benchmark, comme expliqué plus haut.

Ce qui n’a pas été mesuré

• Données. Valeurs plus grandes ou déséquilibrées, mémoire par clé et persistance. La persistance était désactivée sur tous les serveurs.
• Modes. Mode cluster, pub/sub partitionné, TLS, réplication et bascule.
• Fan-out pub/sub. Un message vers de nombreux abonnés.

Redis, Valkey et Dragonfly sont des marques de leurs détenteurs respectifs. Ils ne sont nommés que pour identifier le logiciel mesuré, et cela n’implique ni parrainage, ni approbation, ni affiliation.

Reproduisez-le

Les scripts de balayage, la ligne de lancement et la configuration en direct de chaque serveur, le correctif de pubsub-sub-bench et tous les résultats bruts se trouvent dans le dépôt de benchmarks. Le script de latence est harness/lat_sweep.sh et celui du pub/sub est harness/ps_sweep.sh. Le dossier raw contient une archive par test avec le JSON de memtier_benchmark, les histogrammes HDR et l’utilisation du CPU du serveur pour chaque exécution.

Essayez-le vous-même

HotKV Cloud exécute HotKV pour vous. Démarrez sur HotKV Cloud ou parlez aux ventes pour comparer HotKV à votre propre charge.

Questions fréquentes