Qu'est-ce que le Benchmark Testing ?

Qu'est-ce que le benchmark testing ?

Le benchmark testing mesure la performance d'un système contre une référence fixe : un build précédent, un produit concurrent, une baseline industrie publiée ou un SLO cible. L'output est un nombre comparable (ce build fait 1 800 RPS à p95 de 220 ms versus le build précédent à 1 500 RPS à 240 ms) sur lequel engineering, product et leadership peuvent agir. La référence est tout le point : un seul nombre sans comparateur est non-informatif.

Les benchmarks sont reproductibles par construction. Même hardware, même dataset, même workload mix, même warm-up, même fenêtre de mesure. Un run qui ne peut pas être reproduit n'est pas un benchmark, c'est une seule observation.

Benchmark testing vs load testing

Disciplines adjacentes, questions différentes :

• Benchmark testing : répond à "comment ce build se compare-t-il à ce build ?" Workload fixe, environment fixe, comparable entre runs.
• Load testing : répond à "que se passe-t-il pour ce système sous N utilisateurs concurrents ?" Le workload scale, le but est de trouver le breaking point ou valider contre une cible. Voir load testing.

Tu utilises le load testing pour découvrir la capacité et trouver les bottlenecks. Tu utilises le benchmark testing pour suivre la régression dans le temps et te positionner contre des alternatives. Un load test produit une courbe. Un benchmark produit un nombre.

Quand lancer des benchmark tests

• Avant/après un refactor majeur : mesurer le même workload avant le rewrite et après, confirmer que tu n'as pas régressé sur le throughput ou la latency.
• Avant/après un upgrade de runtime : Node 18 vers Node 22, JDK 17 vers JDK 21, Python 3.10 vers 3.12. Les claims vendor de "30% plus rapide" matchent presque jamais ton workload.
• Avant/après un version bump de base de données : Postgres 14 vers 16, MySQL 5.7 vers 8.0. Les changements de query planner peuvent déplacer la latency per-endpoint dans n'importe quelle direction.
• Au choix entre technologies : Redis vs Memcached, Kafka vs NATS, Postgres vs MySQL. Les benchmarks vendor sont des outils de vente ; construis un benchmark sur ton workload et lance-le.
• Comme gate CI : un benchmark allégé sur chaque PR attrape les régressions multi-pourcent avant le merge. Ne pas gater sur p99 (trop noisy) mais la latency p50 et le throughput total sont utilisables.
• Pour positionnement compétitif : "notre API répond en p95 80 ms ; la leur en 180 ms" est un claim marketing défendable seulement si ta méthodologie de benchmark est publiée.

Caractéristiques clés du benchmark

1. Workload mix fixe : même pourcentage de read vs write, même distribution de paramètres, même flow d'authentication.
2. Environment fixe : même instance type, même région, même réseau. Les nombres cross-environment ne sont pas comparables.
3. Période de warm-up : les runtimes JIT-compiled (JVM, V8, .NET) et les bases cold-cache produisent des nombres lents sur les N premières requêtes ; à jeter.
4. Mesure steady-state : mesurer pendant le plateau, pas pendant ramp-up ou ramp-down.
5. Runs multiples et intervalles de confiance : un seul run peut être noisy ; reporter médiane plus intervalle de confiance sur 5+ runs.
6. Méthodologie publiée : si le prochain engineer ne peut pas relancer ton benchmark depuis le README, il n'est pas reproductible.

Comment lancer les benchmark tests

Choisir un outil qui correspond à ton protocole : JMeter pour large couverture HTTP et protocoles, k6 pour scenarios scriptables et intégration CI, wrk ou wrk2 pour throughput HTTP brut, sysbench pour microbenchmarks de bases de données. Scripter le même workload mix que production (ou une simplification contrôlée).

Stocker l'output du run : requests/sec, latency p50/p95/p99, error rate, CPU, mémoire, plus git SHA et config. Le benchmark n'est utile que quand tu peux le grapher dans le temps et remarquer la régression sur commit X. Coupler les benchmarks avec le regression testing et gater les releases sur les deux.

Lancer des scenarios benchmark depuis LoadFocus contre plusieurs régions cloud et stocker les runs avec metadata. Pour suivre la performance release-après-release avec rigueur engineering, LoadFocus propose des services de load testing où des ingénieurs conçoivent la méthodologie.