08 - Comparatif : k6 vs Artillery vs Autocannon vs wrk

Ce que tu vas apprendre

• Les forces et faiblesses de chaque outil de test de charge
• Lequel choisir selon ton cas d'usage
• Mon opinion apres 2 ans d'utilisation

Prerequisites

Avoir lu le reste de la serie, en particulier les articles sur k6 (02, 03). Ou bien etre en train de choisir un outil et vouloir un avis direct.

Le tableau comparatif

Avant de détailler, voici la vue d'ensemble :

k6 : le choix par défaut

J'utilise k6 pour 90% de mes tests de charge sur paltemps.fr et les projets clients. Voici pourquoi.

Les scripts sont en JavaScript. Pas du YAML, pas du XML JMeter, pas du DSL Scala Gatling. Du JavaScript standard avec des imports ES6. Si tu fais du TypeScript au quotidien, tu es operationnel en 15 minutes.

javascriptimport http from "k6/http";
import { check } from "k6";

export default function () {
  const res = http.get("https://api.example.com/users");
  check(res, { "status 200": (r) => r.status === 200 });
}

Les résultats dans le terminal sont lisibles sans outil supplementaire. Percentiles, checks, throughput, erreurs. Tout est la.

Le binaire fait 30 MB, zero dépendance. Pas de npm install qui tire 400 packages. Pas de runtime Java. Tu telecharges, tu lances, ca marche.

Les thresholds permettent d'intégrer les tests de perf dans le CI. Si la latence p95 dépassé 200ms, le pipeline echoue. C'est automatique.

Les défauts ? La documentation est parfois dispersee entre le site k6.io et la doc Grafana. Les extensions (xk6) necessitent de recompiler le binaire en Go. Et les scripts ne supportent pas npm/node_modules nativement (c'est du JavaScript, pas du Node.js).

Artillery : pour les fans de YAML

Artillery configure les tests en YAML. Si tu trouves que écrire du JavaScript pour un test de charge c'est excessif, Artillery va te plaire.

yamlconfig:
  target: "https://api.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
    - duration: 120
      arrivalRate: 50

scenarios:
  - flow:
      - get:
          url: "/users"
          capture:
            - json: "$[0].id"
              as: "userId"
      - get:
          url: "/users/{{ userId }}/posts"

C'est lisible. Le YAML definit les phases de charge et les scénarios. Pour de la logique plus complexe, tu peux ajouter des hooks en JavaScript.

Artillery supporte Socket.io nativement, ce que k6 ne fait pas. Si ton app utilise Socket.io, c'est un argument fort.

Les défauts : Artillery tourne sur Node.js, donc il consomme nettement plus de mémoire que k6 (200-300 MB pour un test serieux). Il a tendance a saturer la machine de test avant le serveur cible si tu montes a beaucoup de VUs. La version gratuite a des limites sur le reporting, et Artillery Pro est payant.

Autocannon : le quick-and-dirty

Autocannon est créé par Matteo Collina (core contributor Node.js). C'est l'outil le plus simple possible pour un benchmark HTTP rapide :

bashnpx autocannon -c 100 -d 30 https://api.example.com/health

100 connexions, 30 secondes. Autocannon affiche un tableau ASCII avec les latences, le throughput, et les percentiles. C'est tout.

Pas de scénarios. Pas de checks. Pas de scripts. Pas de thresholds. Tu donnes une URL et un nombre de connexions, il bombarde et te donne les chiffres.

Quand j'utilise Autocannon : pendant le développement, pour vérifier rapidement si un changement de code impacte les performances d'un endpoint spécifique. Un npx autocannon prend 5 secondes a lancer. Écrire un script k6 prend 2 minutes. Pendant une session de dev, ces 2 minutes comptent.

L'API programmatique est aussi tres propre :

typescriptimport autocannon from "autocannon";

const result = await autocannon({
  url: "http://localhost:3000/api/health",
  connections: 50,
  duration: 10,
});

console.log(`Throughput: ${result.requests.average} req/s`);
console.log(`Latency p99: ${result.latency.p99}ms`);

Ca s'intégré bien dans un test Bun si tu veux faire du benchmark HTTP dans ta suite de tests (voir la serie Tests fondamentaux).

wrk : la puissance brute

wrk est écrit en C. C'est l'outil le plus performant de la liste. Il peut générer énormément de requêtes par seconde avec tres peu de ressources.

bashwrk -t4 -c200 -d30s https://api.example.com/health

4 threads, 200 connexions, 30 secondes. wrk utilise des sockets non-bloquants et epoll, il est capable de saturer un serveur distant avec une seule machine.

Le scripting est en Lua. C'est fonctionnel mais pas tres ergonomique compare a JavaScript :

luawrk.method = "POST"
wrk.body   = '{"query": "test"}'
wrk.headers["Content-Type"] = "application/json"

Quand j'utilise wrk : quand je veux connaître le throughput maximum absolu d'un endpoint. wrk généré tellement de charge que c'est forcement le serveur qui est le goulot, pas l'outil de test. Pour trouver le breakpoint (voir article 04), c'est l'ideal.

Les défauts : pas de scénarios, pas de checks, pas de thresholds, pas d'export intégré. C'est un outil de mesure brute, pas un framework de test.

Les autres que je n'ai pas retenus

JMeter : l'ancetre. Interface Java Swing, fichiers XML, lourd. Toujours utilise dans les grandes entreprises par inertie. Je n'ai aucune raison de le recommander en 2026.

Gatling : DSL Scala, bon reporting HTML. Si tu fais du Scala, pourquoi pas. Sinon, k6 fait la meme chose en JavaScript.

Locust : Python. Bon outil si ton équipe est Python-first. Les scripts sont lisibles. Mais Python est lent pour générer de la charge, donc il faut plus de machines de test.

Vegeta : Go, ligne de commande, résultats en texte. Similaire a wrk mais en Go. Correct mais k6 fait strictement plus.

Mon avis

Utilise k6 comme outil principal. C'est celui que j'utilise pour tous les tests serieux, les pipelines CI, et les rapports de performance. Si tu ne dois en apprendre qu'un seul, c'est k6.

Garde Autocannon installe pour les benchmarks rapides en dev. Un npx autocannon quand tu veux vérifier un endpoint, c'est imbattable en simplicité.

Si tu as besoin de trouver le throughput max absolu d'un serveur et que k6 n'arrive pas a générer assez de charge (rare mais possible sur un serveur costaud), sors wrk.

Artillery est un bon outil, mais il n'apporte rien que k6 ne fasse pas, sauf le support Socket.io. Si tu utilises Socket.io, prends Artillery. Sinon, k6.

Article précédent : 07 - Soak tests : l'endurance longue duree Article suivant : 09 - Glossaire

Sources

• k6 - Documentation
• Artillery - Documentation
• Autocannon - GitHub
• wrk - GitHub