Outils de benchmark HTTP : wrk, hey, oha, ab et autres

Les outils de benchmark HTTP en ligne de commande que la plupart des équipes utilisent sont wrk, wrk2, hey, oha, ab (Apache Bench), bombardier, autocannon et h2load. Prenez wrk2 si vous avez besoin d’une cadence de requêtes constante et de latences de queue fiables, hey ou oha pour une vérification rapide qui parle aussi HTTP/2, h2load quand c’est HTTP/2 ou HTTP/3 que vous testez, et autocannon si votre équipe travaille en Node.js.

Nous n’avons pas mis ces outils en concurrence, vous ne trouverez donc ici ni chiffres de vitesse ni verdict sur le plus « rapide ». Les informations viennent du dépôt, du manuel ou de la page des versions de chaque projet (vérifiées le 9 octobre 2026) ; les conseils de choix sont notre jugement.

Pourquoi est-il important qu’un outil fixe la cadence ?

Un outil qui maintient un nombre fixe de connexions envoie moins dès que le serveur ralentit, et ses chiffres de latence oublient alors le temps que les requêtes ont passé à attendre. Un outil à cadence fixe continue d’envoyer selon le plan prévu, et le ralentissement apparaît dans les percentiles.

La plupart des outils présentés ici font tourner un nombre donné de connexions ou de workers (-c), chacun attendant une réponse avant d’envoyer la suite. Le README de wrk2 appelle cet angle mort Coordinated Omission et chronomètre chaque requête à partir du moment où elle aurait dû partir. Vegeta maintient lui aussi une cadence constante ; voir notre tour d’horizon des outils de test de charge open source. oha et autocannon peuvent corriger leur latence de cet effet quand une cadence est fixée, tandis que hey et bombardier documentent leurs options de cadence comme de simples plafonds.

wrk vaut-il encore la peine ?

Oui, pour voir rapidement quelle charge une seule machine peut envoyer vers un endpoint, en gardant la réserve ci-dessus à l’esprit. Son tag le plus récent date de février 2021.

wrk est écrit en C et garde un nombre fixe de connexions ouvertes sur plusieurs threads. Des scripts LuaJIT facultatifs peuvent construire les requêtes, traiter les réponses et produire des rapports personnalisés, et make le compile avec les versions de LuaJIT et d’OpenSSL fournies. Il affiche la latence moyenne, l’écart type et le maximum ; --latency ajoute les 50e, 75e, 90e et 99e percentiles.

Choisissez plutôt wrk2 si vous avez besoin d’une cadence de requêtes fixe ou de latences de queue fiables pendant un ralentissement.

Quand faut-il wrk2 plutôt que wrk ?

Quand la question porte sur le comportement de la latence à une cadence de requêtes donnée. wrk2 maintient cette cadence constante et enregistre chaque latence dans un HdrHistogram.

wrk2 ajoute à wrk un argument de débit (-R, en requêtes par seconde). --latency affiche le spectre complet des percentiles et --u_latency ajoute les valeurs non corrigées pour comparaison. Son README prévient que des exécutions de moins de 10 à 20 secondes risquent de ne fournir aucune information utile à cause d’une phase de calibrage de 10 secondes, et qualifie le projet d’expérimental. Il n’a aucune version publiée, et son Makefile produit un binaire qui s’appelle lui aussi wrk : gardez les deux bien séparés.

Choisissez plutôt oha ou autocannon si vous voulez un réglage de cadence avec correction de latence, dans un projet encore maintenu.

hey et oha sont-ils interchangeables ?

Pour des vérifications rapides, en grande partie : les deux font tourner un groupe de workers pour un nombre de requêtes ou une durée, et les deux parlent HTTP/2. Ils diffèrent par leur limitation de cadence et par ce que vous voyez pendant l’exécution.

hey est un petit programme Go avec des binaires prêts à l’emploi pour Linux, macOS et Windows, ainsi qu’une formule Homebrew. -q limite les requêtes par seconde de chaque worker, -h2 active HTTP/2, et le résumé comprend un histogramme des temps de réponse et une distribution des latences, ou du CSV avec -o csv.

oha est écrit en Rust, s’inspire de hey et affiche une interface en direct dans le terminal. Son -q fixe une cadence globale, --latency-correction corrige la Coordinated Omission, et --http-version accepte 1.1, 2 et, dans une compilation expérimentale, 3. Il s’installe avec cargo, Homebrew, winget ou pacman, et sait écrire du JSON ou du CSV.

Choisissez plutôt hey si une limite par worker correspond à votre façon de penser la charge ; choisissez oha pour HTTP/3, le JSON ou la correction de latence.

Faut-il encore utiliser ab ?

Pour une vérification rapide sur une machine où il est déjà installé, oui. ab est livré avec Apache HTTP Server, et son propre manuel énumère des limites connues.

ab prend un nombre de requêtes (-n) et un niveau de concurrence (-c), n’a aucune option de cadence ni de HTTP/2, et n’utilise KeepAlive qu’avec -k. Sa sortie se termine par le pourcentage de requêtes servies en un temps donné ; il peut écrire ces pourcentages en CSV (-e) ou chaque mesure dans un fichier gnuplot (-g). La section Bugs du manuel indique que ab n’implémente pas entièrement HTTP/1.x et prévient que son analyse intensive des chaînes peut vous faire mesurer les performances de ab lui-même.

Choisissez plutôt hey ou oha si vous avez besoin de HTTP/2, d’une limite de cadence ou du keep-alive par défaut.

À quoi servent bombardier et autocannon ?

bombardier est un outil Go avec HTTP/2 en option et une limite de cadence. autocannon convient aux équipes Node.js, car il fonctionne aussi comme bibliothèque dans un script Node.

bombardier utilise par défaut le client fasthttp et passe au client net/http de Go avec --http1 ou --http2. -r fixe une limite de cadence, -l affiche les 50e, 75e, 90e et 99e percentiles, et -o json rend le résultat exploitable par une machine.

autocannon se présente comme un outil HTTP/1.1 avec pipelining et HTTPS, et s’installe avec npm i autocannon -g. -R plafonne la cadence globale et -r celle de chaque connexion, et dès que l’une des deux est fixée, la latence est corrigée de la Coordinated Omission. Son tableau affiche les percentiles 2,5 %, 50 %, 97,5 % et 99 %, -l les affiche tous et -j écrit du JSON.

Choisissez autocannon plutôt que bombardier si vos benchmarks vivent dans une suite de tests Node.js, et bombardier si vous avez besoin de HTTP/2.

Quel outil est conçu pour HTTP/2 et HTTP/3 ?

h2load. Il vient du projet nghttp2, privilégie HTTP/2 et peut forcer HTTP/1.1 ou, s’il a été compilé avec ce support, HTTP/3.

h2load se compile avec nghttp2 en passant --enable-app à ./configure. En plus du nombre de clients (-c), il fixe le nombre de flux simultanés par client (-m) pour tester le multiplexage sous charge, et --rps règle les requêtes par seconde de chaque client. Le manuel donne le minimum, le maximum, la moyenne, la médiane, le p95 et le p99 pour le temps de requête, le temps de connexion et le temps jusqu’au premier octet. Le support de HTTP/3 est signalé comme expérimental.

Choisissez plutôt oha si vous voulez HTTP/2 avec moins d’options et une vue en direct.

Quand passer d’un benchmark à un vrai test de charge ?

Quand la question touche aux parcours utilisateurs, à plus de charge qu’une machine ne peut en générer, ou à du trafic venant de là où se trouvent vos utilisateurs.

Chaque outil présenté ici envoie des requêtes simples depuis une seule machine, et le guide de h2load rappelle que le client lui-même peut devenir le goulet d’étranglement. Passez à un outil de test de charge si vous avez besoin d’authentification, de parcours en plusieurs étapes ou de temps de réflexion, si le trafic doit venir de plusieurs régions, ou si un test doit réussir ou échouer dans la CI. Notre guide Comment faire un test de charge détaille la démarche pas à pas, et k6 vs Artillery compare deux outils scriptables.

LoadFocus, l’éditeur de ce site, exécute des tests de charge pour sites web et API depuis 25 régions cloud, avec JMeter, k6 ou des tests sans code. Si votre benchmark est une requête que vous envoyez déjà avec curl, son convertisseur cURL vers k6 gratuit en fait un script k6, directement dans votre navigateur.

FAQ

Quelle est la différence entre wrk et wrk2 ? wrk2 est un fork de wrk qui envoie les requêtes à une cadence constante fixée avec -R et chronomètre chaque requête à partir du moment où elle aurait dû partir. wrk garde un nombre fixe de connexions occupées et n’a aucun réglage de cadence.

Quels outils de benchmark HTTP prennent en charge HTTP/2 ? D’après leur documentation, hey, oha, bombardier, h2load et Vegeta. wrk et wrk2 ne le documentent pas, autocannon se présente comme un outil HTTP/1.1 et ab n’a pas d’option HTTP/2.

À lire aussi

• Outils de test de charge open source : six options
• Coordinated omission : ce que c’est et comment l’éviter
• Outils de test de charge WebSocket : six options
• Latence de queue : définition et mesure sous charge
• redis-benchmark : l’utiliser et lire ses résultats

Les affirmations techniques de cet article n'ont pas été relues de façon indépendante.