redis-benchmark : l'utiliser et lire ses résultats

31 octobre 2026 8 min de lecture

redis-benchmark est l’utilitaire de benchmark livré avec Redis : il ouvre un certain nombre de connexions clientes (50 par défaut), envoie un nombre fixe de commandes (100 000 par défaut) et indique, pour chaque test, les requêtes par seconde et la latence. Lancez redis-benchmark -q -n 100000 contre un serveur en marche, limitez-le avec -t aux commandes qui vous intéressent, et lisez le résultat comme la vitesse d’une seule instance Redis face à des commandes synthétiques. Votre application ajoute son propre chemin réseau, sa bibliothèque cliente et son mélange de commandes : attendez-vous à d’autres chiffres.

Nous l’avons exécuté le 31 octobre 2026 sur un portable Apple M1 Max, serveur et client Redis 7.2.6 sur la même machine via loopback, sans persistance. Chaque ligne correspond à une exécution de 100 000 requêtes, avec les requêtes par seconde arrondies au millier ; le p50 est reproduit tel qu’affiché.

Exécution	Ce qui change	Requêtes par seconde	p50 (ms)
`-t set,get`	Rien : 50 clients, valeurs de 3 octets	SET 113 000, GET 118 000	0,367 ; 0,351
`-t set,get -P 16`	16 commandes par aller-retour	SET 1 010 000, GET 1 190 000	0,711 ; 0,583
`-t set,get -c 200`	200 clients	SET 117 000, GET 123 000	1,135 ; 1,071
`-t set -d 1024`	Valeurs de 1 024 octets	SET 114 000	0,367
`-t set -r 100000`	Clés aléatoires parmi 100 000	SET 116 000	0,359
`script load "..."`	Une commande personnalisée	106 000	0,415

Comment lancer redis-benchmark ?

Pointez l’outil vers un serveur en marche avec -h et -p ; sans option, il exécute sa série de tests par défaut contre 127.0.0.1:6379. Ajoutez -t pour choisir les tests et -q pour obtenir une ligne par test.

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

La page officielle sur le benchmark de Redis et la sortie --help de la version 7.2.6 listent notamment ces options (vérifié le 31 octobre 2026) :

-c connexions parallèles (50 par défaut) et -n nombre total de requêtes (100 000 par défaut).
-d taille des valeurs SET et GET en octets (3 par défaut).
-P commandes par pipeline (1 par défaut, sans pipelining).
-t une liste de tests séparés par des virgules ; -q sortie réduite ; --csv sortie CSV.
-r clés aléatoires dans un espace de clés de cette taille. Sans cette option, toutes les commandes utilisent la même clé.
-k 1 garde les connexions ouvertes (par défaut), -k 0 se reconnecte.
--threads active le mode multithread ; --cluster active le mode cluster, où -c doit être au moins égal au nombre de nœuds.

Comment lire la sortie de redis-benchmark ?

Avec -q, vous obtenez une ligne par test : les requêtes par seconde et la latence médiane. Sans -q, chaque test affiche ses réglages, une distribution des latences par percentile et un résumé avec la moyenne, le minimum, p50, p95, p99 et le maximum.

L’en-tête affiche aussi les réglages save et appendonly du serveur, qui vous disent si la persistance faisait partie du test. Notre exécution GET complète a donné 119 617 requêtes par seconde, une moyenne de 0,352 ms, un p95 de 0,559 ms, un p99 de 0,623 ms et un maximum de 0,759 ms. Une requête qui appelle Redis de nombreuses fois a plus de chances de tomber sur un appel lent : regardez donc aussi le p99, comme l’explique notre article sur la latence de queue.

--csv affiche le résumé sous forme d’une ligne par test. Répétez les exécutions avant de croire à un petit écart : deux exécutions du même test SET nous ont donné environ 113 000 et 125 000 requêtes par seconde.

Pourquoi le pipelining change-t-il autant les chiffres ?

Sans -P, chaque client attend une réponse avant d’envoyer sa commande suivante, et chaque commande paie un aller-retour complet. Avec -P 16, chaque client en envoie 16 d’un coup, et dans notre exécution SET est passé d’environ 113 000 à 1 010 000 requêtes par seconde, GET de 118 000 à 1 190 000.

La page officielle juge le pipelining réaliste, puisque beaucoup d’applications Redis l’utilisent, et conseille une taille de pipeline proche de la moyenne que votre application peut réellement atteindre. Notre latence médiane a augmenté en même temps, à 0,711 et 0,583 ms.

Que se passe-t-il quand vous ajoutez des clients ?

Une fois le goulot d’étranglement saturé, des clients en plus n’ajoutent que de l’attente. Sur un seul portable, ce peut être le serveur ou le client de benchmark, qui n’a qu’un thread.

En passant de 50 à 200 clients, le débit est resté presque stable (environ 117 000 requêtes SET et 123 000 GET par seconde) tandis que la latence médiane a à peu près triplé, à 1,135 et 1,071 ms. C’est la loi de Little à l’œuvre. Chaque client a au plus une commande en cours, donc -c fixe combien il y en a dans le système, et si le débit ne peut pas croître, c’est le temps que chacune y passe qui croît. Dans notre exécution GET complète, 50 clients ÷ 119 617 requêtes par seconde donnent 0,42 ms par boucle de client, un peu au-dessus de la moyenne mesurée de 0,352 ms. Avec 200 clients, le même calcul donne 1,63 ms.

L’outil suit donc aussi un modèle de charge fermé : quand Redis se bloque, les clients attendent, et les commandes que votre application aurait envoyées entre-temps n’apparaissent jamais. Ni la page officielle ni --help ne listent d’option de cadence de requêtes fixe : lisez ses percentiles en gardant la coordinated omission en tête.

Comment mesurer votre propre commande ou un script Lua ?

Écrivez la commande après les options. L’outil n’exécute alors que cette commande et ignore -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

La première ligne est l’exemple de la page officielle ; sur notre portable, elle a tourné à environ 106 000 requêtes par seconde. SCRIPT LOAD ne fait que charger le script : pour mesurer son exécution, utilisez eval, comme dans la deuxième ligne tirée de --help. Avec -r, l’aide indique que __rand_int__ dans un argument devient un nombre aléatoire à 12 chiffres dans cette plage, et en mode cluster la clé doit contenir un {tag} pour atteindre le bon nœud.

Pourquoi votre application voit-elle d’autres chiffres ?

Votre application mesure tout son chemin jusqu’à Redis : réseau, bibliothèque cliente, sérialisation et son propre mélange de commandes. La page officielle liste des pièges à vérifier avant de comparer.

Une boucle de commandes synchrones mesure surtout le réseau et la bibliothèque cliente.
Avec client et serveur sur une même machine, c’est le CPU qui limite le benchmark. Les sockets de domaine Unix peuvent atteindre environ 50 % de débit en plus que la loopback TCP, sous Linux par exemple.
Des chaînes de 4 Ko à 100 000 requêtes par seconde demandent environ 3,2 Gbit/s, plus que ce que porte un lien à 1 Gbit/s.
Pour comparer Redis à une base transactionnelle, activez AOF et choisissez une politique fsync adaptée.
Les portables font varier la fréquence de leur CPU, ce qui nuit à la reproductibilité.
INFO à intervalles réguliers pose sans doute peu de problèmes pendant une exécution, alors que MONITOR ralentit nettement Redis.

Ces chiffres de portable reflètent-ils la vraie capacité de Redis ?

Non. Ils montrent un portable qui se parle à lui-même, sans réseau, avec des valeurs de 3 octets dans la plupart des cas, sans persistance et une exécution par ligne.

Le tableau montre comment chaque option fait bouger les chiffres. La capacité dépend de votre serveur, de votre réseau, de la taille de vos valeurs et de vos réglages de persistance.

Quand redis-benchmark n’est-il pas le bon outil ?

Quand vous voulez savoir ce que ressentent les utilisateurs. Il envoie des commandes synthétiques à Redis seul, alors que le temps de réponse d’une page inclut aussi le code applicatif et ses autres appels.

Pour cela, mettez sous charge l’application ou l’API qui utilise Redis et surveillez Redis pendant le test. LoadFocus, qui publie ce site, travaille à ce niveau : il exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud contre votre application web ou votre API. Il n’exécute pas redis-benchmark.

Pour mieux contrôler le trafic Redis, le dépôt de memtier_benchmark cite des clients multithread, un ratio lecture:écriture, des motifs de clés aléatoires ou séquentiels, Redis Cluster et TLS (vérifié le 31 octobre 2026).

FAQ

redis-benchmark est-il conçu pour faire paraître Redis rapide ? Non. La page officielle de Redis parle d’une idée reçue répandue : par défaut, l’outil garde au plus une requête en attente par connexion, sans pipelining, et un client qui utilise le pipelining peut générer plus de débit.

Comment remplir une base Redis avec redis-benchmark ? Lancez uniquement le test SET avec des clés aléatoires, comme le montre l’aide de l’outil : -t set -n 1000000 -r 100000000 remplit environ un million de clés. Des clés aléatoires peuvent se répéter, le total final est donc un peu inférieur.

LoadFocus peut-il exécuter redis-benchmark ? Non. LoadFocus n’exécute pas redis-benchmark. Ses plans de test JMeter et ses scripts k6 visent l’application web ou l’API placée devant Redis.