En 2020, lorsque j’écrivais mon premier guide sur les tirs de performance d’Application Gateway, l’écosystème reposait souvent sur des outils lourds en JVM (JMeter, Gatling) ou mono-threadés en Node.js (Artillery).
En 2026, les architectures modernes mêlent APIs REST, flux gRPC, WebSockets et endpoints d’inférence IA en streaming SSE. Pour auditer efficacement un reverse proxy (Caddy, Envoy, Azure AppGW, GCP/AWS LB) sans que la machine d’injection ne devienne elle-même le goulot d’étranglement, voici la suite d’outils de tir de performance que j’utilise en production.
1. Le comparatif de terrain : quel outil pour quel besoin ?
| Outil | Langage Moteur | Modèle d’injection | Point fort majeur | Cas d’usage idéal |
|---|---|---|---|---|
| Grafana k6 | Go (scripté en JS) | Boucle fermée (VUs) ou ouverte (constant-arrival-rate) | Seuils SLO bloquants en CI/CD + export natif Prometheus | Validation de release, parcours API multi-étapes |
| Vegeta | Go | Boucle ouverte pure (taux d’arrivée constant) | Insensible à l’Omission Coordonnée | Stress test de reverse proxy L7 et WAF |
| oha | Rust (tokio) | Boucle ouverte / concurrence fixe | TUI temps réel ultra-visuelle + correction de latence | Diagnostic instantané en ligne de commande |
| ghz | Go | Concurrence / RPS cible | Support natif HTTP/2 + Protobuf / gRPC Reflection | Microservices internes et moteurs d’inférence |
| Locust | Python | Utilisateurs distribués | Flexibilité totale du code Python (auth complexe, SSE) | Simulation de trafic applicatif réaliste |
2. Le piège mortel des tests de charge : l’Omission Coordonnée (Coordinated Omission)
C’est l’erreur numéro 1 observée lors des audits de performance :
- Dans un outil en boucle fermée (Closed-Loop classique où 50 utilisateurs virtuels attendent la réponse de la requête $N$ avant d’envoyer la requête $N+1$), si votre serveur gèle pendant 5 secondes à cause d’un Garbage Collection ou d’un verrou SQLite/NFS, les utilisateurs virtuels s’arrêtent d’envoyer des requêtes pendant la panne !
- Résultat : le serveur est artificiellement soulagé et votre centile
p95paraît excellent alors que la production aurait subi un empilement catastrophique.
Avec k6 (via l’exécuteur constant-arrival-rate) ou Vegeta, l’injecteur maintient implacablement la cadence d’arrivée (arrivalRate), révélant la véritable dégradation perçue par les clients :
// Script k6 moderne (2026) : boucle ouverte à 500 req/s avec garde-fou SLO bloquant
import http from 'k6/http';
import { check } from 'k6';
export const options = {
scenarios: {
open_loop_stress: {
executor: 'constant-arrival-rate',
rate: 500,
timeUnit: '1s',
duration: '2m',
preAllocatedVUs: 100,
maxVUs: 1000,
},
},
thresholds: {
http_req_failed: ['rate<0.001'], // Moins de 0,1 % d'erreurs tolérées
http_req_duration: ['p(99)<250'], // Le p99 doit rester sous 250 ms
},
};
export default function () {
const res = http.get('https://blog.ravindra-job.fr/');
check(res, { 'status is 200': (r) => r.status === 200 });
}
3. Tester ses endpoints gRPC avec ghz
Lorsque vos services communiquent en gRPC (Protobuf sur HTTP/2), les outils HTTP/1.1 classiques sont inopérants. ghz permet de tirer directement à partir du contrat .proto ou par réflexion :
ghz \
--proto ./proto/inference.proto \
--call inference.Predictor/Predict \
-d '{"prompt": "ping"}' \
-c 50 -z 60s --rps 1000 \
blog.ravindra-job.fr:443
Couplée à un export direct vers Prometheus (K6_PROMETHEUS_RW_SERVER_URL), cette boîte à outils permet de corréler à la seconde près la courbe d’injection avec la consommation CPU/RAM (cAdvisor) et la saturation d’IOPS du stockage.