loadtest.app

Loi d'Amdahl : formule, exemples et limites

Sun, 01 Nov 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

La loi d'Amdahl (Amdahl's law) dit que l'accélération obtenue en parallélisant un travail est plafonnée par la part qui ne peut pas s'exécuter en parallèle. Si une fraction p du travail se répartit sur n processeurs, serveurs ou threads, l'accélération vaut S = 1 / ((1 − p) + p/n), et quelle que soit la taille de n, elle ne dépasse jamais 1 / (1 − p). Avec 95 % de travail parallèle, le plafond est de 20 fois, même sur mille machines.

Les chiffres ci-dessous sont de l'arithmétique, sans aucun test derrière. Les articles cités ont été vérifiés le 1er novembre 2026.

Fraction parallèle p	n = 2	n = 8	n = 64	n → ∞
0,50	1,33	1,78	1,97	2
0,90	1,82	4,71	8,77	10
0,95	1,90	5,93	15,42	20
0,99	1,98	7,48	39,26	100

Que dit la loi en termes simples ?

Un travail ne peut pas finir plus vite que sa part séquentielle, donc des workers supplémentaires ne raccourcissent que le reste. Dès que la part parallèle devient petite face à la part séquentielle, ajouter des workers ne change presque plus le temps total.

Prenez un travail de 10 secondes dont 1 seconde est séquentielle (un verrou, une écriture unique) et 9 secondes se répartissent également, soit p = 0,9. Huit workers le terminent en 1 + 9/8 = 2,125 secondes (4,71 fois plus vite) ; soixante-quatre ont besoin d'environ 1,14 seconde. Rien ne le fait passer sous 1 seconde, donc 10 est le plafond.

D'où vient cette loi ?

Gene Amdahl a présenté l'argument en 1967 à l'AFIPS Spring Joint Computer Conference, dans un article qui défendait l'approche à processeur unique.

Nous n'avons pas lu le texte intégral de Validity of the single processor approach to achieving large scale computing capabilities. Mark Hill et Michael Marty le résument dans Amdahl's Law in the Multicore Era (IEEE Computer, 2008) : une fraction parallélisable à l'infini sans surcoût d'ordonnancement, le reste totalement séquentiel, et l'accélération décrite sans présenter d'équation (« without presenting an equation »).

Qu'est-ce que cela change pour les tests de charge et de capacité ?

Le débit cesse de croître au rythme des serveurs, threads ou pods dès qu'un composant partagé traite une partie de chaque requête l'une après l'autre. Un test de charge le montre sous la forme d'une courbe de débit qui s'aplatit pendant que vous continuez à ajouter de la capacité.

L'article de Neil Gunther de 2008, cité plus bas, écrit la même loi sous la forme N / (1 + σ(N − 1)), avec σ la fraction séquentielle, et mesure la scalabilité comme le débit à N divisé par le débit à 1. Dans un système web, la part séquentielle est tout ce que chaque requête doit traverser à son tour : un verrou ou une ligne que chaque requête met à jour, une base de données primaire unique qui reçoit toutes les écritures, un consommateur de file unique ou une API tierce limitée en débit.

Comment trouver la part séquentielle dans un test de charge ?

Lancez le même test à plusieurs niveaux de charge et observez quelle ressource sature pendant que le débit s'aplatit. Le composant qui est à sa limite quand la capacité supplémentaire ne rapporte plus rien est la part séquentielle, ou la file d'attente devant elle.

Signes typiques : le débit plafonne alors que la couche applicative a encore du CPU libre, les attentes grossissent à un seul endroit partagé (verrous, connexions à la base, profondeur de file), et le temps de réponse monte au même rythme que les utilisateurs, ce qui est la loi de Little face à un plafond. Une exécution à charge constante ne peut pas le montrer, donc montez la charge par paliers. Le réglage Ramp Up Steps de LoadFocus ajoute les utilisateurs virtuels par lots égaux. Le panneau de capacité de LoadFocus regroupe une exécution terminée par nombre d'utilisateurs virtuels actifs et, sur les offres payantes, liste le p95, les requêtes par seconde et le taux d'erreur par palier pour les exécutions à un seul générateur de charge. Il n'indique un niveau de capacité que si l'exécution a franchi au moins trois paliers, le palier le plus haut valant au moins le double du plus bas. Il n'ajuste aucun modèle de scalabilité : l'ajustement décrit plus bas est à faire vous-même.

Qu'est-ce que la loi de Gustafson ?

C'est le contrepoint : si le problème grandit avec la machine, la part séquentielle reste petite et l'accélération croît presque linéairement. Amdahl fixe le travail, Gustafson fixe le temps d'exécution.

La note de John Gustafson de 1988, Reevaluating Amdahl's law, rapportait des accélérations de 1016 à 1021 sur un hypercube de 1024 processeurs à Sandia, pour des applications dont la part séquentielle était de 0,4 à 0,8 %, et soutenait que les utilisateurs agrandissent le problème jusqu'à remplir le temps dont ils disposent. Avec s' la part séquentielle mesurée sur l'exécution parallèle, l'accélération mise à l'échelle, une formule que la note attribue à E. Barsis à Sandia, vaut N + (1 − N)s'.

Avec s' = 0,05 et 64 processeurs, cela donne 60,85, contre 15,42 selon Amdahl, parce que les deux valeurs de 5 % sont mesurées sur des machines différentes. Dans un système web, Gustafson s'applique quand chaque serveur ajouté travaille sur sa propre part des données ; Amdahl s'applique quand chaque utilisateur supplémentaire touche toujours la même ligne partagée.

Qu'apporte l'Universal Scalability Law ?

Un second terme pour la cohérence, c'est-à-dire le coût de garder des données partagées cohérentes entre workers, qui croît avec le nombre de paires de workers. Avec lui, le débit peut atteindre un maximum puis baisser à mesure que vous ajoutez de la capacité.

L'article de Gunther A General Theory of Computational Scalability Based on Rational Functions (arXiv, 2008) énonce l'Universal Scalability Law (USL) ainsi :

C(N) = N / (1 + σ(N - 1) + κN(N - 1))
peak at N* = sqrt((1 - σ) / κ)

σ représente la contention (sérialisation ou mise en file) et κ la cohérence (copies incohérentes des données) ; avec κ = 0, on retrouve la formule d'Amdahl. Parmi les exemples de Gunther pour le pire cas figure la mise à jour d'enregistrements en base, et il qualifie le débit au-delà de N* de « retrograde », c'est-à-dire décroissant. Avec les valeurs d'exemple σ = 0,05 et κ = 0,001, le maximum se situe vers 31 workers : le débit relatif vaut 9,03 à 32 et 7,82 à 64, là où le terme σ seul prévoit 15,42.

Comment ajuster l'USL sur une série de tests de charge ?

Mesurez le débit à plusieurs niveaux de concurrence, divisez chaque valeur par le débit à un utilisateur, puis estimez σ et κ par la méthode des moindres carrés.

Réarrangée, la formule s'écrit N / C − 1 = σ(N − 1) + κN(N − 1), ce qui est linéaire en σ et κ. Les valeurs ci-dessous sont générées à partir de σ = 0,05 et κ = 0,001 ; mettez dans x vos propres requêtes par seconde par palier :

import numpy as np

n = np.array([1, 2, 4, 8, 16, 32])          # virtual users
x = np.array([50, 95, 172, 284, 402, 452])  # req/s per level
c = x / x[0]                                # relative capacity
A = np.column_stack([n - 1, n * (n - 1)])
(s, k), *_ = np.linalg.lstsq(A, n / c - 1, rcond=None)
print(f"sigma={s:.3f} kappa={k:.4f}")
print(f"peak near {np.sqrt((1 - s) / k):.0f} users")

Le script affiche sigma=0.050, kappa=0.0010 et un maximum vers 31 utilisateurs. Ne changez que la concurrence d'un palier à l'autre et incluez un palier à un utilisateur, puisque chaque point est divisé par lui.

Où ces modèles cessent-ils d'être utiles ?

Ils résument une courbe de débit en une ou deux constantes, donc ils ne peuvent ni désigner le verrou en cause ni suivre un système qui change sous la charge. Servez-vous-en pour lire une courbe mesurée et la prolonger un peu : un ajustement sur des paliers loin sous le coude dit peu de chose du maximum.

Paramètres constants. Un cache en cours de préchauffage, un autoscaler ou un pool qui atteint sa limite modifie σ et κ en cours de test.
Le débit seulement. Le p95 et le p99 peuvent se dégrader en premier : vérifiez aussi la latence de queue.
Le générateur de charge. S'il sature d'abord, la courbe plate est la sienne.
Tests fermés. Des utilisateurs virtuels en nombre fixe mesurent un système fermé ; les vrais utilisateurs arrivent à leur propre rythme.

FAQ

Pouvez-vous expliquer la loi d'Amdahl simplement ? Un travail n'est jamais plus rapide que la part qui ne peut pas être partagée. Si un dixième du travail doit s'exécuter en séquence, aucun nombre de workers supplémentaires ne le rend plus de dix fois plus rapide, car ce dixième prend toujours le même temps.

Qu'est-ce que la loi de Gustafson ? La loi de Gustafson dit que lorsque le problème grandit avec le nombre de processeurs, l'accélération croît presque linéairement, selon N + (1 − N)s', avec s' la part séquentielle de l'exécution parallèle. John Gustafson l'a publiée en 1988 (en attribuant la formule à son collègue de Sandia E. Barsis) en contrepoint de l'hypothèse d'Amdahl d'un problème de taille fixe.

Théorie des files d'attente : ce qu'elle dit de la latence

Sun, 01 Nov 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

La théorie des files d'attente (en anglais queueing theory) est la mathématique de l'attente : à partir du rythme d'arrivée du travail, de la durée de chaque tâche et du nombre de serveurs, elle prédit combien de temps les tâches attendent et quelle longueur atteint la file. Pour le logiciel, son résultat le plus utile est que le temps de réponse augmente lentement sous charge modérée, puis brusquement quand un serveur approche 100 % d'occupation. Dans le modèle le plus simple, un serveur occupé 90 % du temps répond en moyenne dix fois plus lentement qu'un serveur inactif.

Les chiffres ci-dessous sont des calculs tirés de formules classiques, vérifiés par un script, sans test derrière. Les sources ont été vérifiées le 1er novembre 2026.

Taux d'utilisation ρ	Temps dans le système W ÷ temps de service S	Si S = 20 ms
0,5	2	40 ms
0,7	3,3	67 ms
0,8	5	100 ms
0,9	10	200 ms
0,95	20	400 ms
0,99	100	2 000 ms

Ce sont des moyennes pour la file M/M/1 : un serveur, des arrivées de Poisson et des temps de service exponentiels.

Qu'est-ce que la théorie des files d'attente ?

C'est la branche des probabilités qui modélise un travail qui arrive, attend puis est servi. Une file se décrit par ses arrivées, ses temps de service, son nombre de serveurs et sa discipline de service, c'est-à-dire l'ordre dans lequel les tâches en attente sont prises.

Urban Operations Research de Larson et Odoni, un texte du MIT en libre accès, cite les guichets de banque, les caisses de supermarché et les péages comme cas classiques. Un serveur web entre dans le même cadre : les requêtes arrivent, des threads ou des cœurs les traitent, et les autres attendent dans une file.

D'où vient la théorie des files d'attente ?

Du central téléphonique, où A. K. Erlang a obtenu les premiers résultats pour la compagnie des téléphones de Copenhague.

Selon sa biographie MacTutor, l'article d'Erlang de 1909 montrait que des appels passés au hasard suivent la loi de Poisson, et sa formule de 1917 sur les pertes et le temps d'attente a vite été adoptée par des compagnies de téléphone de nombreux pays. L'article de David Kendall de 1953, Stochastic Processes Occurring in the Theory of Queues and their Analysis by the Method of the Imbedded Markov Chain, a introduit la notation encore en usage, comme le rappelle le récit de son œuvre par Geoffrey Grimmett. La démonstration de L = λW par Little et les résultats de Kingman en trafic dense ont suivi en 1961.

Que signifie la notation de Kendall, comme M/M/1 ?

Elle nomme une file en trois parties, A/S/c : la loi des intervalles entre arrivées, celle des temps de service et le nombre de serveurs. M/M/1 signifie des arrivées aléatoires, des temps de service exponentiels et un seul serveur.

M signifie memoryless, sans mémoire (arrivées de Poisson ou temps exponentiels), D déterministe et G general, c'est-à-dire n'importe quelle loi : M/D/1 est un serveur dont le temps de service est constant.

Comment le temps de réponse augmente-t-il avec le taux d'utilisation ?

Dans une file M/M/1, le temps moyen passé dans le système est W = 1/(μ − λ), soit S/(1 − ρ). Quand le taux d'utilisation ρ approche 1, W croît sans limite.

lambda = arrival rate        mu = service rate (1 / S)
rho    = lambda / mu         (utilization, must stay below 1)
W      = 1 / (mu - lambda)   = S / (1 - rho)

Larson et Odoni le démontrent pour un centre d'appels à une seule opératrice et montrent qu'il n'existe pas de régime stationnaire pour ρ ≥ 1 : la file ne cesse de s'allonger. La même source montre que le temps dans le système suit une loi exponentielle. Chaque percentile augmente donc du même facteur 1/(1 − ρ), et le p95 vaut environ trois fois la moyenne : 600 ms sur la ligne 0,9 ci-dessus.

Pourquoi la latence fait-elle un coude avant que le CPU atteigne 100 % ?

Parce qu'une requête attend chaque fois qu'elle trouve le serveur occupé, ce qui arrive de plus en plus souvent quand le taux d'utilisation monte. Sous les hypothèses M/M/1, le temps de réponse a déjà doublé à 50 % d'utilisation.

La ressource qui sature peut aussi être un pool de connexions, un verrou de base de données ou une boucle d'événements à un seul thread, et la plus chargée dicte la courbe. C'est ce coude précoce qui explique pourquoi le taux d'utilisation visé reste bien en dessous de 100 %. Partez de votre budget de latence : avec S = 20 ms et une moyenne cible de 100 ms, le tableau autorise environ 80 %, et une cible de 60 ms environ 67 %, avant que les pics de trafic ne prennent leur part.

Le panneau de capacité de LoadFocus regroupe un test terminé par nombre d'utilisateurs virtuels actifs et indique le dernier palier qui a tenu avant que le taux d'erreur dépasse 1 % ou que le p95 dépasse le double du meilleur palier, à condition qu'aucun palier supérieur ne se soit rétabli. Il lui faut un test sur un seul générateur de charge qui monte sur au moins trois paliers, le plus haut valant au moins le double du plus bas. D'après le calcul ci-dessus, si le palier le plus léger a laissé le goulot d'étranglement presque inactif, le doublement se déclenche juste au-delà de 50 % d'utilisation ; s'il le chargeait déjà à ρ0, le doublement se déclenche plus tard, au-delà de (1 + ρ0)/2 sous M/M/1.

Pourquoi la variabilité compte-t-elle autant que le taux d'utilisation ?

Les files naissent du hasard : des arrivées en rafales et des tâches parfois lentes. En trafic dense, le temps d'attente croît avec la variabilité des deux, multipliée par un terme ρ/(1 − ρ).

L'article de Kingman de 1961, The single server queue in heavy traffic, montre que lorsque l'intensité de trafic d'un serveur unique est proche de 1, la file est longue et le temps d'attente suit à peu près une loi exponentielle. Des notes de cours de la TU Eindhoven et du Technion en donnent une approximation de la moyenne (le Technion l'appelle approximation d'Allen-Cunneen ; elle est aussi largement connue sous le nom de formule de Kingman) :

Wq ≈ rho / (1 - rho) × (ca² + cs²) / 2 × S
ca, cs = coefficient of variation (std dev / mean)
         of arrival gaps and of service times

Wq est l'attente avant le début du service, et ca, cs sont les coefficients de variation. Des temps exponentiels ont c² = 1, ce qui redonne l'attente M/M/1 de 9S à 90 % d'utilisation. Un temps de service constant la divise par deux, à 4,5S ; cs² = 4, ce que peut produire un mélange de succès de cache et d'appels lents à la base de données, la porte à 22,5S. Un trafic synthétique régulier varie moins que la production, donc un test montre en général moins d'attente que les vrais pics.

Comment plusieurs serveurs (M/M/c) aident-ils ?

Plusieurs serveurs qui partagent une file absorbent bien mieux les rafales aléatoires que les mêmes serveurs avec une file chacun, si bien que chaque serveur peut être plus occupé pour la même attente.

D'après les formules M/M/m de Larson et Odoni, avec chaque serveur occupé à 90 %, W vaut 10S pour un serveur, 5,3S pour deux partageant une file et 3,0S pour quatre. Quatre instances derrière un répartiteur de charge qui choisit une instance libre se comportent comme le dernier cas ; quatre qui reçoivent chacune un quart aléatoire du trafic, comme des files M/M/1 séparées à 10S.

Quel lien avec la loi de Little ?

La loi de Little, L = λW, relie le nombre moyen de requêtes dans un système à leur taux d'arrivée et à leur temps de séjour, quelles que soient les lois. La théorie des files d'attente donne W, et la loi de Little en tire L.

Sur la ligne 0,9, 45 requêtes par seconde avec W = 200 ms donnent en moyenne 9 requêtes dans le système. Notre article sur la loi de Little utilise la même loi pour dimensionner et vérifier des tests de charge.

Où ces modèles cessent-ils de s'appliquer en test de charge ?

Ils supposent un flux ouvert d'arrivées indépendantes et un régime stationnaire. Un test avec un nombre fixe d'utilisateurs virtuels est un système fermé, où les arrivées ralentissent quand les réponses ralentissent.

Tests fermés. Avec N utilisateurs virtuels, il y a au plus N requêtes dans le système, donc la cadence de requêtes baisse là où une file ouverte s'allongerait, et le temps de réflexion la réduit encore. Notre article sur le modèle de charge ouvert ou fermé explique pourquoi cela masque la saturation.
LoadFocus exécute des scripts k6, mais les scénarios arrival-rate y tournent avec un nombre fixe d'utilisateurs, comme le signale son validateur de scripts. Lisez ces tests comme des tests fermés : après le coude, attendez-vous à une cadence de requêtes plate et à des temps de réponse qui montent.
Régime stationnaire. La phase de chauffe, les caches et l'autoscaling changent le taux de service pendant le test, donc comparez des paliers tenus assez longtemps pour se stabiliser.

FAQ

Faut-il écrire queueing theory ou queuing theory ? Les deux orthographes anglaises sont correctes et désignent le même domaine. L'article de Kingman de 1961 écrit « queueing time », tandis que la démonstration de Little, la même année, porte « Queuing Formula » dans son titre.

La théorie des files d'attente exige-t-elle des arrivées de Poisson ? Seulement pour les résultats exacts du modèle M/M/1. Les approximations G/G/1 comme la formule de Kingman utilisent la moyenne et la variabilité des intervalles entre arrivées et des temps de service, et la loi de Little ne suppose rien sur les lois.

SLO vs SLA : la différence, les SLI et le budget d'erreur

Sun, 01 Nov 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Un SLA (accord de niveau de service) est un contrat avec un client qui dit ce qui se passe quand un service n'atteint pas un niveau promis, le plus souvent un crédit de service. Un SLO (objectif de niveau de service) est la cible interne sur laquelle une équipe pilote le service ; le livre SRE conseille de la fixer plus stricte que le SLA pour que les problèmes soient réglés avant que le contrat ne soit enfreint. Un SLI (indicateur de niveau de service) est la mesure dans laquelle les deux sont exprimés, par exemple la part des requêtes qui réussissent.

	SLI	SLO	SLA
Ce que c'est	Une mesure	Une cible pour un SLI	Un contrat fondé sur des SLO
Fixé par	L'ingénierie	Le product owner et l'ingénierie	Les équipes commerciales et juridiques
En cas d'échec	Rien en soi	Budget d'erreur consommé	Crédits de service ou pénalités
Exemple	Appels de paiement réussis	99,95 % sur quatre semaines	99,9 % par mois, sinon un crédit

Les exemples sont des illustrations ; les sources sont le livre SRE et le workbook SRE de Google ainsi que le SLA Amazon Compute, vérifiés le 1er novembre 2026.

Que signifient SLI, SLO et SLA ?

Service level indicator, service level objective et service level agreement : indicateur, objectif et accord de niveau de service. L'indicateur est ce que vous mesurez, l'objectif la valeur que vous visez, et l'accord ce que vous promettez à quelqu'un d'autre, avec des conséquences à la clé.

Le chapitre « Service Level Objectives » du livre SRE définit un SLA comme « un contrat explicite ou implicite avec vos utilisateurs qui prévoit des conséquences si les SLO qu'il contient sont respectés (ou manqués) ». Le test du chapitre tient en une question : que se passe-t-il si les SLO ne sont pas atteints ? Sans conséquence explicite, vous avez presque certainement affaire à un SLO.

Le chapitre ajoute que la plupart des gens pensent SLO quand ils disent SLA, et qu'une vraie violation de SLA peut finir en procès pour rupture de contrat. Quand une réunion tourne au débat SLA vs SLO, demandez donc d'abord si une conséquence, en général financière, est inscrite dans un contrat.

Le livre SRE conseille de garder une marge de sécurité : « un SLO interne plus strict que le SLO annoncé aux utilisateurs vous laisse le temps de réagir aux problèmes chroniques avant qu'ils ne deviennent visibles de l'extérieur ». Son chapitre « Embracing Risk » applique la même idée à un contrat : un objectif externe de 99,9 % adossé à un objectif interne plus exigeant.

Qu'est-ce qu'un budget d'erreur ?

C'est 100 % moins le SLO : la part des requêtes ou du temps qui peut échouer dans la fenêtre. Tant qu'il reste du budget, l'équipe continue de livrer ; une fois épuisé, le travail de fiabilité passe en premier.

Le chapitre « Implementing SLOs » du workbook SRE donne le calcul : avec un SLO de 99,9 %, un service qui reçoit 3 millions de requêtes sur quatre semaines peut en faire échouer 3 000, si bien qu'une panne de 1 500 erreurs consomme la moitié du budget. Le chapitre « Embracing Risk » du livre en explique le but : la gestion produit fixe le SLO, le monitoring mesure la disponibilité réelle, et l'écart est la marge de non-fiabilité qui reste pour le trimestre. Quand ce budget est épuisé, les mises en production sont arrêtées ou ralenties.

Combien d'indisponibilité permet 99,9 % ?

Environ 43 minutes sur une fenêtre de 30 jours. Chaque neuf supplémentaire divise la marge par dix, si bien que 99,99 % laisse à peine plus de 4 minutes.

SLO	Budget d'erreur	Indisponibilité sur 30 jours	Échecs par million
99 %	1 %	7 h 12 min	10 000
99,5 %	0,5 %	3 h 36 min	5 000
99,9 %	0,1 %	43 min 12 s	1 000
99,95 %	0,05 %	21 min 36 s	500
99,99 %	0,01 %	4 min 19 s	100

Multipliez les 43 200 minutes d'une fenêtre de 30 jours par le budget d'erreur. Gardez en tête l'avertissement du workbook : chaque neuf supplémentaire coûte plus cher alors que son intérêt pour les utilisateurs tend vers zéro.

À quoi ressemble un vrai SLA ?

Il fixe un pourcentage mesuré, une période de facturation, un barème de crédits et ce qui ne compte pas. Le SLA Amazon Compute en est un exemple public et court.

L'Amazon Compute Service Level Agreement (mis à jour le 25 mai 2022 ; vérifié le 1er novembre 2026) s'engage sur un Monthly Uptime Percentage d'au moins 99,99 % par région pour les instances EC2 réparties sur deux Availability Zones ou plus, et 99,5 % pour une instance seule. La disponibilité vaut 100 % moins la part des minutes pendant lesquelles EC2 était indisponible. Selon le Region-Level SLA, sous 99,99 %, le crédit vaut 10 % de la facture EC2 du mois dans la région, sous 99,0 % il vaut 30 %, et sous 95,0 % il vaut 100 % ; pour une instance seule, le palier à 10 % commence sous 99,5 %. Les crédits s'imputent sur les paiements futurs, doivent être réclamés via le support AWS et constituent le recours « seul et exclusif », sauf disposition contraire du contrat client.

Rapporté au tableau d'indisponibilité, le palier à 10 % du Region-Level SLA couvre d'environ 4 minutes à 7 heures d'indisponibilité sur un mois de 30 jours. Un SLA plafonne ce que le fournisseur doit ; empêcher les pannes de nuire à vos utilisateurs, c'est le rôle de vos propres objectifs.

Comment choisir des SLI pour la latence et la disponibilité ?

Mesurez la latence en percentile et la disponibilité en événements réussis divisés par tous les événements, au plus près de l'utilisateur. Les moyennes et les mesures prises au seul serveur masquent les requêtes dont on se plaint.

Latence. Le livre SRE préfère les percentiles à la moyenne, car une moyenne peut rester plate pendant que les requêtes les plus lentes ralentissent nettement. Le workbook écrit les SLI de latence comme un ratio, par exemple les appels terminés en moins de 100 ms divisés par tous les appels. « 99 % des appels de paiement en moins de 400 ms » revient donc à « p99 du paiement sous 400 ms » sur la fenêtre, ce qui se reporte tel quel dans un test. Notre article sur la latence de queue explique pourquoi le p99 compte dès qu'une page appelle plusieurs services.

Disponibilité. La disponibilité temporelle compte les minutes de fonctionnement, comme le fait le SLA d'AWS. La disponibilité par requêtes compte les requêtes réussies : « Embracing Risk » décrit un service de 2,5 millions de requêtes par jour avec un objectif quotidien de 99,99 %, qui peut renvoyer 250 erreurs et tenir quand même son objectif.

Où les SLO dérapent-ils ?

Le plus souvent par excès d'objectifs, par des cibles à 100 % et par des indicateurs mesurés là où les utilisateurs ne sont pas. Chacun produit un chiffre sur lequel personne n'agit, ou un chiffre qui semble bon pendant que les utilisateurs souffrent.

Trop de SLO. Le livre SRE conseille d'en avoir le moins possible : si citer un SLO ne permet jamais de gagner une discussion sur les priorités, il ne vaut probablement pas la peine.
Des cibles à 100 %. Le workbook juge que 100 % est la mauvaise cible : les composants tombent en panne, le changement est la première source de pannes, et un SLO à 100 % ne laisse que le temps de réagir.
Mesurer seulement au serveur. Les métriques serveur ratent des problèmes que les utilisateurs ressentent, comme un script lent dans la page. Le workbook propose de mesurer au load balancer ou côté client.

Quel rapport entre le test de charge et les SLO ?

Un SLO fournit au test de charge ses critères de réussite, et un test au pic attendu montre si le SLO de latence tiendra avant que ce trafic n'arrive. Le monitoring de production ne vous le dit qu'après coup.

Le livre SRE note qu'un nombre plus élevé de requêtes par seconde (QPS) entraîne souvent des latences plus grandes et que les services présentent fréquemment une falaise de performance au-delà d'un certain seuil de charge. Un test de charge peut trouver cette falaise s'il tourne au pic attendu, avec un mélange de requêtes réaliste, et mesure le SLI qu'utilise le SLO. Fixez chaque seuil du test un peu plus strict que le SLO, comme le décrit notre guide des critères de réussite d'un test de charge. Une exécution dure quelques minutes et ne peut donc pas mesurer une disponibilité mensuelle.

LoadFocus, qui publie ce site, juge les tests de charge sur des seuils de réussite enregistrés sur le test : Max P95 et Max P99 du temps de réponse, un taux d'erreur maximal et un débit minimal, pour les tests cloud, JMeter et k6. Son monitoring d'API propose des rapports SLA et SLO qui fixent un objectif SLO par moniteur et affichent la disponibilité, le budget d'erreur consommé et un statut OK ou Dépassé.

FAQ

Que signifie SLO ? Service level objective, ou objectif de niveau de service : une valeur cible pour un niveau de service mesuré, par exemple 99,9 % de requêtes réussies sur quatre semaines. Il est fixé en interne, par le produit et l'ingénierie, et n'entraîne en soi aucune pénalité contractuelle.

Peut-on avoir un SLO sans SLA ? Oui. Le livre SRE cite la recherche Google comme un service important sans SLA public, qui est pourtant piloté avec des SLI et des SLO.

Un SLO devrait-il valoir 100 % ? Non. Un objectif de 100 % ne laisse aucun budget d'erreur, si bien que chaque échec l'enfreint et qu'aucun changement n'est jamais sûr à livrer.

TPC-H : ce que mesure le benchmark et comment le lancer

Sun, 01 Nov 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

TPC-H est le benchmark d'aide à la décision du Transaction Processing Performance Council (TPC) : 22 requêtes métier et deux fonctions de rafraîchissement s'exécutent sur huit tables que le programme dbgen du TPC remplit selon un facteur d'échelle choisi, le facteur 1 correspondant à environ 1 Go. Sa métrique, QphH@Size, combine un test de puissance à un seul flux et un test de débit à plusieurs flux, et les résultats officiels ajoutent un prix par kQphH@Size. Seuls les résultats audités publiés sur tpc.org sont officiels ; tout chiffre de type TPC-H publié hors de tpc.org compte comme une charge dérivée selon les règles d'usage loyal du TPC et ne doit pas être comparé aux résultats officiels.

Nous n'avons pas exécuté le benchmark pour ce guide. Les faits proviennent de tpc.org, de la spécification en révision 3.0.1, que tpc.org désigne comme actuelle, et de la documentation de chaque outil, le tout vérifié le 1er novembre 2026. Les appréciations sont les nôtres.

	TPC-H	TPC-C	TPC-DS
Charge	Aide à la décision : requêtes ad hoc plus mises à jour des données	OLTP : les commandes d'un grossiste	Aide à la décision : requêtes plus maintenance des données
Périmètre	8 tables, 22 requêtes, 2 fonctions de rafraîchissement	9 types de tables, 5 types de transactions	Schéma en flocon, 7 tables de faits, 99 requêtes
Métrique principale	QphH@Size et $/kQphH@Size	tpmC	QphDS@SF et $/kQphDS@SF
Version actuelle	3.0.1	5.11.0	4.0.0

Que mesure TPC-H ?

La vitesse à laquelle un système répond à des requêtes analytiques complexes sur un gros volume de données, pendant que de nouvelles ventes arrivent et que d'anciennes sont supprimées. Une seule spécification définit le schéma, les requêtes, les données et les règles.

La page TPC-H décrit une suite de requêtes ad hoc orientées métier accompagnées de modifications de données simultanées (vérifié le 1er novembre 2026). La spécification définit huit tables : PART, PARTSUPP, LINEITEM, ORDERS, CUSTOMER, SUPPLIER, NATION et REGION. Toutes sauf les deux dernières grandissent avec le facteur d'échelle ; LINEITEM, la plus grande, compte environ 6 000 000 de lignes par unité. La fonction de rafraîchissement RF1 insère de nouvelles lignes dans ORDERS et LINEITEM, et RF2 supprime d'anciennes ventes (vérifié le 1er novembre 2026).

Comment le score TPC-H est-il calculé ?

Une exécution enchaîne un test de puissance puis un test de débit, et QphH@Size est la moyenne géométrique des deux résultats. La métrique de prix est le prix total du système divisé par QphH@Size, multiplié par 1 000.

Dans le test de puissance, un flux de rafraîchissement exécute RF1, une session de requêtes unique exécute les 22 requêtes une fois, puis le flux de rafraîchissement exécute RF2. Power@Size vaut 3 600 fois le facteur d'échelle, divisé par la moyenne géométrique de ces 24 durées. Dans le test de débit, plusieurs flux de requêtes tournent à côté d'un flux de rafraîchissement : au moins 2 au facteur 1, jusqu'à 11 au facteur 100 000. Throughput@Size correspond aux requêtes par heure sur l'ensemble des flux, multipliées par le facteur d'échelle. Un test complet comporte deux exécutions, et le sponsor publie celle dont le QphH est le plus bas (le tout d'après la spécification, vérifié le 1er novembre 2026).

La moyenne géométrique donne le même poids à chaque requête : diviser par deux la durée d'une seule requête n'augmente Power que d'environ 3 %. Un résultat officiel utilise un facteur d'échelle pris dans une liste fixe : 1, 10, 30, 100 et ainsi de suite jusqu'à 100 000.

Qui publie les résultats TPC-H, et lesquels comptent ?

Les éditeurs qui parrainent un test publient des résultats audités sur tpc.org, et seuls ceux-là sont officiels. Toute autre exécution est une charge dérivée, soumise à ses propres règles.

La spécification impose un audit indépendant par un auditeur certifié par le TPC. Le guide rapide sur l'usage loyal (fair use) du TPC n'autorise le nom du TPC à côté de résultats que pour les résultats officiels publiés. Tout le reste doit porter le préfixe « Derived from », ne peut pas utiliser la métrique du TPC, doit afficher un avertissement indiquant qu'il n'est pas comparable aux résultats publiés, devrait décrire son environnement et ses écarts, et ne peut pas être comparé aux résultats officiels (vérifié le 1er novembre 2026).

Comment lancer TPC-H vous-même ?

Générez les données et le texte des requêtes, chargez les tables, puis lancez le test de puissance suivi du test de débit. Vous pouvez utiliser les outils du TPC, un kit conçu pour une base de données précise ou un moteur doté d'un générateur intégré.

La page des spécifications actuelles du TPC propose un paquet d'outils gratuit : vous vous inscrivez, acceptez une licence et recevez le lien par e-mail. Selon la spécification, DBGen doit produire les données et QGen le texte des requêtes (vérifié le 1er novembre 2026).

Pour PostgreSQL, la page TPC-H du wiki ne donne pas de procédure pas à pas et renvoie vers DBT-3, un kit complet que la page DBT-3 du wiki présente comme une implémentation de la spécification conforme à l'usage loyal. HammerDB fournit TPROC-H, que sa documentation décrit comme une charge open source dérivée de TPC-H et non comparable aux résultats publiés. Il fonctionne sur PostgreSQL, MySQL, Oracle et d'autres moteurs, et la documentation recommande de comparer la moyenne géométrique des durées de requêtes plutôt que de calculer un QphH (le tout vérifié le 1er novembre 2026).

DuckDB dispose d'une extension tpch qui, d'après sa documentation, implémente le générateur de données et les requêtes. Ces lignes génèrent le facteur 1, exécutent la requête 4 et listent les 22 requêtes :

CALL dbgen(sf = 1);
PRAGMA tpch(4);
FROM tpch_queries();

La même page prévient que les données diffèrent légèrement de la spécification, que chaque requête s'exécute avec des paramètres fixes et que dbgen ne supprime pas les tables existantes. Pour des données entièrement conformes, elle renvoie vers tpchgen-cli (vérifié le 1er novembre 2026).

Comment lire honnêtement des résultats TPC-H ?

Ne comparez des résultats qu'au même facteur d'échelle et dans la même version du benchmark, et lisez chaque métrique avec son suffixe de taille. Un graphique de durées de requêtes isolées ne montre ni le test de puissance ni le test de débit.

La page des résultats regroupe les résultats par taille de base et porte trois mentions : les résultats des versions 2 et 3 ne sont pas comparables, le rapport prix/performance dans des devises différentes ne doit pas être comparé, et les comparaisons entre tailles de base sont trompeuses (vérifié le 1er novembre 2026). La spécification ajoute que des résultats avec des nombres de flux différents sont comparables à taille de base égale.

Pour une exécution informelle, cherchez ce que demandent les règles d'usage loyal : matériel et mémoire, modifications du schéma ou du texte des requêtes, et présence ou non des fonctions de rafraîchissement. Un article qui chronomètre les 22 requêtes une seule fois, cache chaud, sans flux de rafraîchissement, ne couvre que le volet requêtes d'un test de puissance, même si une telle exécution reste utile pour suivre vos propres régressions. Sur le lien entre cadence de requêtes et temps de réponse, voir débit vs latence.

Quand utiliser autre chose que TPC-H ?

Quand la charge est transactionnelle, quand vous voulez un benchmark analytique plus récent, ou quand la question porte sur ce que vivent les utilisateurs. Le benchmark modélise une charge analytique, sans transactions courtes ni couche applicative.

Choisissez TPC-DS pour un test d'aide à la décision plus large : sa spécification en version 4.0.0 utilise un schéma en flocon avec sept tables de faits et 99 requêtes, et sa page de présentation indique que les résultats de la version 4 ne sont pas comparables aux versions précédentes. Choisissez TPC-C, ou le TPROC-C de HammerDB, pour de l'OLTP de type saisie de commandes : la page TPC-C décrit cinq types de transactions mesurés en tpmC (le tout vérifié le 1er novembre 2026). Pour un contrôle rapide d'une seule base, pgbench couvre PostgreSQL et sysbench couvre MySQL.

LoadFocus, qui publie ce site, n'exécute pas TPC-H ; ses tests visent des endpoints web et API. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud, sans pilote JDBC ni module SQL, et ne peut donc pas se connecter à la base de données. Pour ce travail, choisissez un outil de benchmark de base de données comme l'extension de DuckDB, DBT-3 ou HammerDB plutôt que LoadFocus, et utilisez LoadFocus pour la couche web ou API placée devant la base, en partant de son modèle pour les endpoints derrière les requêtes lourdes.

FAQ

Quelle est la différence entre TPC-H et TPC-DS ? Ce sont deux benchmarks d'aide à la décision du TPC. TPC-H utilise 8 tables et 22 requêtes et publie QphH@Size, tandis que TPC-DS utilise un schéma en flocon avec sept tables de faits et 99 requêtes et publie QphDS@SF.

Que signifie QphH@Size dans TPC-H ? C'est la métrique composite de requêtes par heure : la moyenne géométrique des résultats du test de puissance et du test de débit pour une taille de base donnée. Le suffixe indique cette taille, par exemple QphH@1000GB, et des résultats obtenus à des tailles différentes ne doivent pas être comparés.

LoadFocus peut-il exécuter TPC-H ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6 visant des endpoints web et API et n'a pas de connexion SQL : utilisez un outil de benchmark de base de données pour TPC-H et LoadFocus pour la couche applicative placée devant la base.

pgbench : benchmark et test de charge de PostgreSQL

Sat, 31 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

pgbench est le programme de benchmark livré avec PostgreSQL : il exécute la même transaction SQL encore et encore dans plusieurs sessions de base de données simultanées et rapporte les transactions par seconde et la latence. Vous créez ses tables de test avec pgbench -i -s 50 mydb, puis une commande comme pgbench -c 10 -j 2 -T 300 mydb lance dix clients sur deux threads pendant cinq minutes. Il mesure la base de données seule, et ne dit donc rien de ce que vivent les utilisateurs à travers l'application placée devant.

Nous n'avons pas exécuté pgbench pour ce guide. Les faits proviennent de la page pgbench de la documentation de PostgreSQL 18, la version que postgresql.org désigne comme actuelle, vérifiés le 31 octobre 2026, et les appréciations sont les nôtres.

Option	Effet
`-i` / `-s`	Créer les tables de test / facteur d'échelle (100 000 comptes par unité)
`-c`	Clients, c'est-à-dire sessions de base de données simultanées (1 par défaut)
`-j`	Threads de travail dans pgbench (1 par défaut)
`-T` / `-t`	Durée en secondes, ou nombre de transactions par client (10 par défaut)
`-b` / `-f`	Script intégré ou fichier à vous, avec un `@poids` facultatif
`-P`	Rapport de progression toutes les N secondes
`-R` / `-L`	Débit visé en tps / limite de latence en ms
`-r` / `-l`	Latences par instruction / une ligne de journal par transaction

Que mesure pgbench ?

Il exécute un script de transaction encore et encore dans un nombre fixé de sessions de base de données, puis rapporte le taux moyen de transactions et la latence. Le script par défaut s'inspire librement du benchmark bancaire TPC-B.

D'après la documentation de pgbench, le scénario par défaut est inspiré de TPC-B sans être vraiment TPC-B, d'où son nom : la sortie l'appelle TPC-B (sort of) (vérifié le 31 octobre 2026).

Comment préparer une base pour pgbench ?

Lancez pgbench -i sur une base existante, avec -s pour le facteur d'échelle. La commande crée quatre tables et supprime toute table existante portant le même nom : donnez-lui une base à part.

Au facteur 1, pgbench_branches contient une ligne, pgbench_tellers 10, pgbench_accounts 100 000 et pgbench_history aucune, et -s multiplie ces lignes : -s 100 donne 10 000 000 de lignes dans pgbench_accounts. La documentation n'indique aucune taille sur disque, mesurez-la donc après l'initialisation (vérifié le 31 octobre 2026).

Quels scripts intégrés pgbench propose-t-il ?

Trois : tpcb-like (par défaut), simple-update et select-only. Vous en choisissez un avec -b, ou avec les raccourcis -N et -S.

Le script par défaut envoie sept commandes par transaction : BEGIN, un update et un select sur un compte au hasard, des updates sur pgbench_tellers et pgbench_branches, un insert dans pgbench_history, puis END. simple-update retire les deux updates sur les petites tables, ce qui y évite la contention et, selon la documentation, éloigne encore le test de TPC-B. select-only n'envoie que le select.

Comment écrire un script pgbench personnalisé ?

Mettez votre SQL dans un fichier, définissez des variables avec \set et les fonctions aléatoires, et passez le fichier avec -f. Chaque exécution du fichier compte comme une transaction.

\set aid random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta
  WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
END;

Un poids après @ fixe la fréquence de choix de chaque script : -f update.sql@9 -b select-only@1 choisit le fichier environ neuf fois sur dix. La documentation liste aussi random_exponential, random_gaussian et random_zipfian, qui permettent de rendre quelques lignes très sollicitées. \sleep ajoute une pause, l'équivalent côté base de données du temps de réflexion. Si vous n'exécutez que vos propres fichiers, passez le facteur d'échelle de la base avec -s, sinon :scale reste à 1 et le script ci-dessus ne touche que les 100 000 premiers comptes. Avec vos propres tables, omettez -i et ajoutez -n pour que pgbench ne lance pas de VACUUM sur les tables standard (vérifié le 31 octobre 2026).

Quelles options font de pgbench un test de charge ?

La concurrence vient de -c et -j, la durée de -T et la forme de la charge de -R. Sans -R, chaque client lance sa transaction suivante dès que la précédente se termine.

Ce comportement par défaut correspond à un modèle de charge fermé, expliqué dans notre article sur le modèle de charge ouvert ou fermé. Avec -R, pgbench lance les transactions selon un calendrier à distribution de Poisson qui avance à partir du démarrage du client, quel que soit le sort des transactions précédentes. La latence rapportée compte alors à partir de chaque départ prévu et inclut donc le retard sur le calendrier (schedule lag), dont la moyenne et le maximum sont affichés à part : c'est la correction que décrit notre article sur la coordinated omission. Le nombre de clients reste fixe ; si le retard ne cesse de grandir, le système ne tient pas ce débit avec les clients et threads choisis : baissez -R ou ajoutez des clients.

--latency-limit (-L) compte comme en retard les transactions qui dépassent une limite en millisecondes ; avec -R, pgbench saute en plus les transactions déjà trop en retard sur le calendrier et les rapporte comme ignorées. -M prepared utilise des requêtes préparées, plus rapides que les autres modes selon la documentation (vérifié le 31 octobre 2026).

Comment lire la sortie de pgbench ?

Le résumé liste les réglages, les transactions traitées et en échec, la latence moyenne, le temps de connexion initial et le tps. La forme ci-dessous vient de la documentation, sans les chiffres :

transaction type: <builtin: TPC-B (sort of)>
number of transactions actually processed: ...
number of failed transactions: ... (...%)
latency average = ... ms
latency stddev = ... ms   (only with -P, -R or -L)
initial connection time = ... ms
tps = ... (without initial connection time)

Les transactions en échec sont des erreurs de sérialisation ou des deadlocks, que --max-tries peut relancer. Les autres erreurs SQL interrompent le client concerné et donnent un code de sortie 2. Le résumé ne donne aucun percentile : pour la latence de queue, journalisez chaque transaction avec -l, qui enregistre sa durée en microsecondes, et calculez vous-même le p95 ou le p99.

Sans -P, -R ou -L, la latence moyenne du résumé n'est pas mesurée : pgbench la déduit de la durée du test et du nombre de clients, soit la loi de Little appliquée à l'envers, échecs compris. Ajoutez -P quand la latence compte.

Comment obtenir des chiffres pgbench fiables ?

Faites durer chaque exécution plusieurs minutes, répétez-la, gardez un facteur d'échelle au moins égal au nombre de clients et surveillez le VACUUM. Si pgbench devient lui-même le goulot d'étranglement, déplacez-le sur une autre machine.

La première consigne de la section « Good Practices » de la documentation met en garde contre tout test qui ne dure que quelques secondes, et ajoute que des chiffres reproductibles peuvent demander des heures (vérifié le 31 octobre 2026). Avec le script par défaut, un facteur d'échelle inférieur au nombre de clients mesure surtout la contention des updates, car pgbench_branches n'a que -s lignes et chaque transaction en modifie une. Les lignes mortes et l'autovacuum font varier les résultats d'une exécution à l'autre. Avec beaucoup de sessions, pgbench peut saturer sa propre machine : lancez-le sur une machine séparée avec une faible latence réseau, ou répartissez plusieurs instances sur plusieurs machines.

Quand pgbench n'est-il pas le bon outil ?

Quand la question porte sur les utilisateurs, sur une autre base de données ou sur un mélange OLTP standard. pgbench mesure PostgreSQL seul, sans votre pool de connexions, votre ORM, votre cache ni votre couche HTTP.

Pour voir ce que vivent les utilisateurs, mettez sous charge la couche HTTP ou API placée devant. LoadFocus, qui publie ce site, n'exécute pas pgbench et ne peut pas se connecter directement à PostgreSQL : LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud contre des endpoints web et API, et son modèle pour les endpoints derrière les requêtes lourdes offre un point de départ.

Choisissez plutôt sysbench pour MySQL : son dépôt décrit un outil de benchmark scriptable et multithread, avec des tests de base de données de type OLTP. Choisissez HammerDB pour un mélange de type TPC-C : sa documentation décrit TPROC-C, une charge dérivée de TPC-C, qu'il exécute sur PostgreSQL et d'autres moteurs. Choisissez JMeter avec son sampler JDBC Request pour mêler SQL et HTTP dans un même plan de test sur vos propres machines (le tout vérifié le 31 octobre 2026).

FAQ

À quoi sert l'option -s de pgbench ? Elle fixe le facteur d'échelle à l'initialisation. Chaque unité ajoute 100 000 lignes à pgbench_accounts, donc -s 100 crée 10 000 000 de lignes. Avec le script par défaut, gardez-le au moins égal à votre nombre de clients.

Quelle est la différence entre -c et -j dans pgbench ? L'option -c fixe le nombre de clients simulés, chacun étant une session de base de données simultanée. L'option -j fixe le nombre de threads de travail de pgbench qui se partagent ces clients.

LoadFocus peut-il exécuter pgbench ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6 et n'a pas de connexion directe à PostgreSQL : avec lui, vous mettez sous charge la couche web ou API placée devant la base de données.

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

Sat, 31 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

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.

Utiliser sysbench : benchmarks CPU, disque et MySQL

Sat, 31 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

sysbench est un outil de benchmark open source et multithread, bâti sur LuaJIT, qui fournit des tests CPU, mémoire, E/S fichiers, threads et mutex, ainsi que des scripts OLTP pour MySQL et PostgreSQL. Les tests qui ont besoin de données suivent le même cycle : prepare crée les fichiers ou les tables de test, run lance le benchmark pendant une durée ou un nombre d'événements donné, et cleanup supprime les données ; les tests CPU et mémoire n'ont besoin que de run. Il mesure une machine ou un serveur de base de données, et ne peut donc pas vous dire comment votre application se comporte face à un vrai trafic d'utilisateurs.

Nous n'avons pas exécuté sysbench pour ce guide. Les faits proviennent de son README et de son code source sur la branche master de GitHub, vérifiés le 31 octobre 2026, et les conseils sont les nôtres.

Sujet	sysbench
Licence	GPLv2
Écrit en	C, avec LuaJIT pour les scripts
Dernière version	1.0.20 (24 avril 2020)
Dernier commit	9 mars 2025
Tests intégrés	`cpu`, `memory`, `fileio`, `threads`, `mutex`
Scripts de base de données	Huit scripts `oltp_`, `bulk_insert`, deux `select_random_`
Pilotes de base de données	MySQL (par défaut), PostgreSQL
Plateformes	Linux, macOS ; Windows via WSL

sysbench est-il encore maintenu ?

Peu. La dernière version, la 1.0.20, date d'avril 2020 ; la branche master a reçu depuis des commits occasionnels, dont aucun n'est sorti dans une version, le dernier en mars 2025.

La version 1.0.20 est datée du 24 avril 2020. L'historique des commits montre des changements comme une distribution uniforme par défaut pour --rand-type (2020), un LuaJIT upstream (2023) et la prise en charge des bibliothèques client MariaDB (2023), puis quatre commits de build le 9 mars 2025 (vérifié le 31 octobre 2026). Les dépôts de paquets cités dans le README sont mis à jour à chaque version : ces changements demandent donc une compilation depuis les sources.

Comment se déroule une exécution de sysbench ?

Vous indiquez un test et une commande : sysbench [options] [testname] [command]. Le test est un test intégré, un script Lua fourni ou votre propre script, et la commande est en général prepare, run, cleanup ou help.

Selon le README, prepare crée les fichiers pour fileio ou remplit la base pour les scripts OLTP, cleanup supprime ces données, et sysbench <testname> help liste les options d'un test. Un test de disque :

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

Le code source de fileio liste les modes seqwr, seqrewr, seqrd, rndrd, rndwr et rndrw, avec 2 Go de fichiers par défaut. Des fichiers qui tiennent en mémoire peuvent être servis par le cache de pages : prévoyez un volume supérieur à la RAM si c'est le disque que vous voulez mesurer.

Comment mesurer le CPU et la mémoire avec sysbench ?

Avec sysbench cpu run et sysbench memory run. Le test CPU indique des événements par seconde, un événement consistant à vérifier la primalité de chaque nombre jusqu'à une limite, et le test mémoire indique des opérations et des Mio transférés par seconde.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

Le test CPU fixe --cpu-max-prime à 10000 par défaut, et le test mémoire accepte une taille de bloc, une taille totale, des opérations de lecture ou d'écriture et un accès séquentiel ou aléatoire (vérifié le 31 octobre 2026). Ne comparez que des exécutions aux réglages identiques.

Comment tester MySQL ou PostgreSQL avec sysbench ?

Choisissez un des scripts OLTP fournis, remplissez les tables avec prepare, lancez des transactions depuis plusieurs threads avec run, puis supprimez les tables avec cleanup. MySQL est le pilote par défaut ; PostgreSQL demande --db-driver=pgsql et un build compilé avec le support de PostgreSQL.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

Le script OLTP commun crée une table de 10 000 lignes si vous ne passez pas --tables et --table-size. Dans oltp_read_write, chaque transaction exécute 10 lectures par clé, quatre requêtes sur des plages, deux mises à jour et une suppression suivie d'une insertion, entre BEGIN et COMMIT (vérifié le 31 octobre 2026). Prévoyez des données plus grandes que le buffer pool du serveur si vous voulez des lectures disque dans le résultat.

Quelles options de sysbench comptent le plus ?

--threads et --time fixent la taille et la durée d'une exécution, --rate fixe un taux cible d'événements, et --report-interval, --percentile et --histogram déterminent ce que vous voyez.

--threads : threads de travail, 1 par défaut.
--time : durée en secondes, 10 par défaut, 0 pour aucune limite. --events plafonne le nombre d'événements, et les deux limites s'appliquent : associez-le à --time=0.
--warmup-time : tourne d'abord sans statistiques, pour que des caches froids ne faussent pas le résultat. Branche master uniquement : la version 1.0.20 ne l'a pas.
--rate : nombre moyen d'événements par seconde pour l'ensemble des threads ; 0, la valeur par défaut, signifie le plus vite possible.
--report-interval : des chiffres par intervalle toutes les N secondes, pour révéler les blocages.
--percentile : le percentile de latence affiché, 95 par défaut.
--histogram : un histogramme des latences en fin d'exécution, défini dans sb_logger.c.

sysbench suit-il un modèle de charge fermé ou ouvert ?

Fermé par défaut : un nombre fixe de threads lancent chacun l'événement suivant dès que le précédent se termine, si bien qu'un serveur lent reçoit moins d'événements. Avec --rate, les événements arrivent selon leur propre calendrier, ce qui se rapproche d'un modèle de charge ouvert.

Notre article sur le modèle de charge ouvert ou fermé explique pourquoi cela change ce que mesure un benchmark. En mode par défaut, un blocage retarde aussi les événements qui auraient démarré pendant ce temps, et ces retards n'apparaissent jamais dans les latences : c'est la coordinated omission. Le fichier source principal montre que --rate place les événements dans une file à des intervalles suivant une loi exponentielle, ajoute à la latence de chaque événement son temps d'attente dans la file, et s'arrête avec l'erreur "event queue is full" quand les threads ne suivent plus (vérifié le 31 octobre 2026).

Comment lire les résultats de sysbench ?

Commencez par le débit : événements par seconde, ou transactions et requêtes par seconde pour les scripts OLTP. Lisez ensuite le bloc de latence en millisecondes : minimum, moyenne, maximum, le percentile choisi (p95 par défaut) et la somme.

La version 1.0.20 affiche à la place de « Throughput » un bloc « General statistics » avec la durée totale et le nombre total d'événements. Les noms de champs viennent du code du rapport base de données et du fichier source principal sur master, ici sans valeurs :

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Un 95e percentile laisse de côté l'événement le plus lent sur vingt. Passez --percentile=99 ou ajoutez --histogram quand la queue de distribution compte ; notre guide sur la latence de queue explique pourquoi.

Quand sysbench n'est-il pas le bon outil ?

Quand votre question porte sur votre application. Un score CPU montre à quelle vitesse une machine vérifie des nombres premiers, et une exécution OLTP mesure le serveur de base de données avec les tables et requêtes de sysbench, sans votre schéma, votre pool de connexions ni le chemin réseau.

Choisissez pgbench pour des tests propres à PostgreSQL : la documentation de PostgreSQL décrit un scénario par défaut vaguement inspiré de TPC-B, ainsi que des fichiers de script personnalisés (vérifié le 31 octobre 2026).
Choisissez HammerDB pour des tests de type TPC-C : sa documentation couvre la charge TPROC-C, dérivée de TPC-C, pour SQL Server, Db2, Oracle, PostgreSQL, MariaDB et MySQL (vérifié le 31 octobre 2026).
Choisissez JMeter avec son sampler JDBC Request pour mêler SQL et HTTP dans un même plan de test ; le guide des plans de test de base de données indique que le .jar du pilote va dans le dossier lib de JMeter.

LoadFocus, qui publie ce site, n'exécute pas sysbench et ne peut pas se connecter lui-même à MySQL ou PostgreSQL. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud contre la couche web ou API placée devant la base. Une combinaison utile : une exécution de sysbench pour dimensionner le serveur de base de données, puis un test de charge de l'application pour voir si de vraies requêtes atteignent cette limite.

FAQ

sysbench est-il encore maintenu ? Peu. La dernière version est la 1.0.20 du 24 avril 2020. La branche master a reçu depuis des commits occasionnels, aucun dans une version, le plus récent le 9 mars 2025.

Que signifie le 95e percentile dans les résultats de sysbench ? C'est la latence, en millisecondes, en dessous de laquelle 95 % des événements se sont terminés. 95 est la valeur par défaut de l'option --percentile, et vous pouvez en choisir une autre, comme 99.

sysbench peut-il tester PostgreSQL ? Oui. Les scripts OLTP fournis tournent contre PostgreSQL avec --db-driver=pgsql quand sysbench a été compilé avec le support de PostgreSQL.

LoadFocus peut-il exécuter sysbench ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6 contre des sites web et des API depuis 25 régions cloud, et ne se connecte pas directement à MySQL ou PostgreSQL.

YCSB : charges de travail A-F, exécution et limites

Sat, 31 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

YCSB, le Yahoo! Cloud Serving Benchmark, est un outil open source écrit en Java qui charge des enregistrements synthétiques dans une base de données, puis y exécute un mélange fixe de lectures, de mises à jour, d'insertions et de scans en mesurant le débit et la latence de chaque opération. Ses six charges de travail de base (core workloads), de A à F, sont des mélanges standard : le même test peut donc tourner sur Cassandra, MongoDB, Redis, HBase et des dizaines d'autres bases grâce à des bindings. Il mesure la base de données seule et ne dit donc rien des vraies requêtes de votre application ni de la latence que voient vos utilisateurs.

Nous n'avons pas exécuté YCSB pour cet article. Les faits proviennent de son dépôt GitHub, de son wiki et de son code source, vérifiés le 31 octobre 2026, et les appréciations sont les nôtres.

Charge de travail	Mélange d'opérations	Distribution des clés	Exemple donné par le wiki
A : mises à jour intensives	50 % lectures, 50 % mises à jour	zipfian	Stockage de sessions qui enregistre les actions récentes
B : surtout des lectures	95 % lectures, 5 % mises à jour	zipfian	Ajout de tags sur des photos
C : lecture seule	100 % lectures	zipfian	Cache de profils utilisateur
D : lecture des plus récents	95 % lectures, 5 % insertions	latest	Statuts publiés par les utilisateurs
E : plages courtes	95 % scans, 5 % insertions	zipfian (scans de 100 enregistrements au plus)	Fils de discussion
F : lecture-modification-écriture	50 % lectures, 50 % lecture-modification-écriture	zipfian	Base d'utilisateurs

Les mélanges viennent des fichiers du répertoire workloads et les exemples de la page Core Workloads (vérifié le 31 octobre 2026). Chaque fichier ne contient que 1 000 enregistrements et 1 000 opérations : assez pour déboguer une installation, beaucoup trop peu pour un benchmark.

Qu'est-ce que YCSB, et est-il encore maintenu ?

C'est un générateur de charge accompagné de charges de travail standard pour comparer des bases clé-valeur et de type « cloud serving », publié en open source par Yahoo! en 2010 sous licence Apache 2.0. La dernière version date d'octobre 2019, et le code reçoit encore de petits commits.

La page des publications cite l'article d'origine, « Benchmarking Cloud Serving Systems with YCSB », de Cooper, Silberstein, Tam, Ramakrishnan et Sears (ACM SoCC 2010). La version 0.17.0 est datée du 6 octobre 2019 et aucun tag plus récent n'existe, alors que l'historique des commits montre du travail en 2026, comme une option pour continuer après un échec d'insertion et une modification du binding Cloud Spanner le 20 octobre (vérifié le 31 octobre 2026). Ces changements ne sont disponibles qu'en compilant depuis les sources, ce qui demande Maven 3.

Comment lancer un benchmark YCSB ?

En deux phases qui partagent les mêmes propriétés : load insère recordcount enregistrements, puis run exécute operationcount opérations selon le mélange de la charge de travail. Vous indiquez le binding de votre base et passez le fichier de la charge de travail avec -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

La page Running a Workload détaille les pièges courants (vérifié le 31 octobre 2026). Le client ne crée jamais de table : vous associez d'abord usertable à ce dont votre base a besoin, par exemple une table dans MySQL ou un keyspace dans Cassandra. Les fichiers -P placés plus loin écrasent les précédents, et -p les écrase tous. La phase d'exécution doit recevoir le même recordcount que le chargement, car elle choisit ses clés dans l'ensemble des données. -s affiche une ligne d'état toutes les 10 secondes. Comme D et E insèrent des enregistrements, la page Core Workloads conseille de charger une fois avec le fichier de A, d'exécuter A, B, C, F et D, puis de supprimer les données et de recharger pour E.

Que règlent -threads et -target ?

-threads fixe le nombre de threads clients qui envoient des opérations (un par défaut), et -target plafonne le nombre total d'opérations par seconde. Sans cible, chaque thread envoie l'opération suivante dès que la précédente revient : une base plus lente reçoit donc tout simplement moins de charge.

C'est un modèle de charge fermé, et notre article sur le modèle de charge ouvert ou fermé explique ce qu'il masque. L'exemple du wiki, 10 threads pour une cible de 100 opérations par seconde, ne tient que tant que la latence moyenne reste sous 100 ms ; avec trop peu de threads, le débit atteint reste sous la cible. C'est la loi de Little : le nombre de threads divisé par la latence moyenne plafonne le débit. En lançant plusieurs cibles et en relevant la latence à chacune, vous obtenez la courbe décrite dans notre guide débit vs latence.

Comment lire la sortie de YCSB ?

À la fin de chaque phase, le client affiche un bloc [OVERALL] avec la durée et le débit, puis un bloc par type d'opération avec le nombre d'opérations, les latences moyenne, minimale, maximale et par percentile, et un décompte par code de retour.

Ces noms de champs viennent du code source de la 0.17.0 ; les valeurs sont des exemples fictifs :

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

L'exemple de sortie du wiki affiche des millisecondes, mais la mesure HdrHistogram par défaut, dans la 0.17.0 comme dans le code actuel, indique des microsecondes, (us). La page Core Properties et la version 0.17.0 fixent les percentiles par défaut à 95 et 99, modifiables avec hdrhistogram.percentiles ; depuis avril 2025, la branche master ajoute 50, donc une compilation depuis les sources affiche aussi 50thPercentileLatency(us) (vérifié le 31 octobre 2026). Le README oriente vers le P99 et au-delà, rappelle qu'on ne peut pas faire la moyenne de percentiles et conseille, avec plusieurs clients, d'enregistrer des fichiers d'histogramme HDR avec hdrhistogram.fileoutput=true puis de les fusionner.

YCSB tient-il compte de la coordinated omission ?

Seulement si vous le demandez, et seulement avec -target. Par défaut, chaque latence est mesurée à partir du moment où l'opération est réellement envoyée : un blocage qui retarde les opérations suivantes se voit donc à peine.

Le code source des mesures prévoit une propriété measurement.interval qui accepte op (par défaut), intended ou both (vérifié le 31 octobre 2026). Avec une cible, chaque thread note le départ prévu de chaque opération ; intended mesure la latence à partir de ce moment, et both ajoute des blocs Intended- comme [Intended-READ] à côté des blocs habituels. Le wiki ne mentionne pas cette propriété : vérifiez le code de la version que vous compilez. Notre guide sur la coordinated omission explique pourquoi le départ prévu donne le chiffre honnête.

Quelles bases de données YCSB peut-il tester ?

Toute base qui dispose d'un binding. Le fichier de build de la branche master liste 46 modules de binding, parmi lesquels Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB et un binding JDBC générique.

La liste figure dans le pom.xml, et chaque répertoire de binding a son propre README avec les propriétés de connexion, comme mongodb.url pour le binding MongoDB (vérifié le 31 octobre 2026). D'après la page Running a Workload, une seule machine cliente suffit pour des clusters d'une dizaine de machines ; au-delà, vous lancez plusieurs clients, et la page Running a Workload in Parallel répartit la charge entre eux avec insertstart et insertcount.

Quand YCSB n'est-il pas le bon outil ?

Quand votre question porte sur votre application. La charge de travail de base écrit des enregistrements synthétiques, 10 champs d'une longueur de 100 chacun par défaut, au moyen d'opérations simples sur des clés : elle ne peut donc pas montrer comment vos propres requêtes, vos index ou le code de votre API se comportent sous charge.

Pour l'OLTP relationnel, pgbench exécute sur PostgreSQL un script inspiré de TPC-B et accepte vos propres scripts, et sysbench fournit des benchmarks Lua de type OLTP (tous deux vérifiés le 31 octobre 2026).
Pour la latence que voient les utilisateurs, mettez sous charge la couche HTTP ou API placée devant la base. LoadFocus, qui publie ce site, exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud sur des endpoints web et API. LoadFocus n'exécute pas YCSB.

FAQ

Quelles sont les charges de travail de base de YCSB ? Six mélanges standard : A compte 50 % de lectures et 50 % de mises à jour, B 95 % de lectures, C uniquement des lectures, D privilégie les enregistrements insérés le plus récemment, E fait des scans courts et F des lectures-modifications-écritures.

Quelle est la différence entre ycsb load et ycsb run ? La phase de chargement insère le nombre d'enregistrements fixé par recordcount. La phase d'exécution lance ensuite operationcount opérations selon le mélange de la charge de travail sur ces enregistrements et indique le débit et la latence.

YCSB est-il encore maintenu ? La dernière version, la 0.17.0, est sortie le 6 octobre 2019. Le dépôt reçoit encore des commits de temps en temps, le plus récent le 20 octobre 2026 : les correctifs récents demandent donc de compiler depuis les sources.

LoadFocus peut-il exécuter des benchmarks YCSB ? Non. LoadFocus n'exécute pas YCSB. Ses plans de test JMeter et ses scripts k6 visent des endpoints web et API, c'est-à-dire la couche placée devant la base de données.

Test de charge NBomber : le framework .NET passé en revue

Wed, 21 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

NBomber est un framework de test de charge pour .NET : vous écrivez chaque test comme un scénario C# ou F#, vous l'ajoutez à un projet ordinaire et vous le lancez comme n'importe quel programme. Le test de charge avec NBomber convient aux équipes qui développent déjà en .NET et veulent leurs tests de charge dans le même langage, le même dépôt et le même lanceur de tests. NBomber n'est gratuit que pour un usage personnel et académique ; une entreprise a besoin d'une licence payante, et ce seul point tranche plus d'évaluations que n'importe quelle fonctionnalité.

Nous n'avons pas exécuté NBomber pour cette revue. Les faits proviennent de la documentation, de la page de tarifs, du dépôt GitHub et du paquet NuGet de NBomber, vérifiés le 21 octobre 2026, et les appréciations sont les nôtres.

Sujet	NBomber
Licence	Gratuit pour un usage personnel et académique ; payant pour les organisations
Prix pour une entreprise	Business 1 500 $ par an, Enterprise 2 500 $ par an
Version actuelle	6.7.1 (16 octobre 2026)
Environnement d'exécution	.NET Standard 2.1, donc .NET Core 3.0 ou plus récent
Tests écrits en	Scénarios C# ou F#
Modèle de charge	Inject (taux d'arrivée) ou copies constantes
Contrôles de réussite	Seuils pendant l'exécution, asserts sur les statistiques finales
Montée en échelle	NBomber Cluster, licence Enterprise

Qui développe NBomber, et est-il gratuit ?

NBomber LLC le développe, avec le code source sur GitHub. Il est gratuit pour un usage personnel, de loisir et académique, et la page de licence dit clairement que NBomber n'est pas gratuit pour les organisations.

La page de licence range les benchmarks, les tutoriels et les contenus de revue dans l'usage personnel. En entreprise, il faut une licence Business ou Enterprise, attribuée par organisation et non par poste de développeur, sans limite d'instances ni d'exécutions parallèles. La page de tarifs indique 1 500 $ par an pour Business et 2 500 $ par an pour Enterprise, toutes deux avec une garantie de remboursement de 30 jours. La clé de licence se passe au lanceur avec .WithLicense(...) ou un argument --license, et NBomber a besoin d'un accès à internet pour la valider, une validation hors ligne étant possible sur demande par e-mail (vérifié le 21 octobre 2026).

La dernière version est la v6.7.1, publiée le 16 octobre 2026, quatre jours après la 6.7.0 (vérifié le 21 octobre 2026).

Comment fonctionne un scénario NBomber ?

Un scénario, c'est un nom et une fonction asynchrone que NBomber chronomètre à chaque appel. Vous y attachez des simulations de charge et des seuils, vous l'enregistrez auprès de NBomberRunner et vous lancez le programme.

Ce test saute le warm-up, fait monter le taux d'arrivée à 50 nouvelles copies du scénario par seconde en deux minutes, le maintient dix minutes et se termine avec le code de sortie 1 si 1 % ou plus des requêtes ont échoué. Il utilise le plugin NBomber.Http pour la requête :

var http = Http.CreateDefaultClient();

var scenario = Scenario.Create("browse", async context =>
{
    var request = Http.CreateRequest("GET",
        "https://staging.example.com/products");
    return await Http.Send(http, request);
})
.WithoutWarmUp()
.WithLoadSimulations(
    Simulation.RampingInject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(2)),
    Simulation.Inject(rate: 50,
        interval: TimeSpan.FromSeconds(1),
        during: TimeSpan.FromMinutes(10)))
.WithThresholds(
    Threshold.Create(s => s.Fail.Request.Percent < 1));

var result = NBomberRunner
    .RegisterScenarios(scenario).Run();
return result.Thresholds.Any(t => t.IsFailed) ? 1 : 0;

La page du client HTTP recommande Http.CreateDefaultClient() plutôt qu'un simple new HttpClient() et indique que le plugin suit les codes de statut et les données transférées (vérifié le 21 octobre 2026). Un seuil seul ne fait que consigner l'échec dans le rapport : c'est la dernière ligne qui en fait un code de sortie lisible par un pipeline. Sans .WithoutWarmUp(), NBomber lance d'abord un warm-up de 30 secondes avec les simulations du scénario, d'après la page des scénarios (vérifié le 21 octobre 2026). Comme le scénario est du C# ordinaire, tout ce qu'une bibliothèque .NET peut appeler se teste en charge de la même façon.

Quels modèles de charge NBomber propose-t-il ?

Les deux. Les simulations inject lancent de nouvelles copies à un rythme fixé, quoi que fassent les copies précédentes, ce qui donne un modèle de charge ouvert ; les simulations constant maintiennent un nombre fixe de copies, ce qui donne un modèle fermé.

La page des simulations de charge les énumère (vérifié le 21 octobre 2026) :

Ouvertes : Inject, RampingInject, InjectRandom et IterationsForInject.
Fermées : KeepConstant, RampingConstant et IterationsForConstant.
Temporisation : Pause, qui retarde le démarrage d'un scénario ou le suspend pendant une durée donnée.

Notre article sur le modèle de charge ouvert ou fermé explique lequel correspond à votre trafic. Un site public se comporte en général comme le modèle ouvert, un groupe fixe de clients internes plutôt comme le modèle fermé.

Comment fonctionnent les seuils et les contrôles de réussite ?

Les seuils évalués pendant l'exécution contrôlent les statistiques en cours, toutes les 5 secondes par défaut, et apparaissent dans le rapport HTML. Les asserts, écrits avec xUnit ou NUnit, contrôlent les statistiques finales après l'exécution, et un assert en échec termine l'exécution avec un statut d'échec.

La page des seuils montre des contrôles sur le pourcentage d'erreurs, les codes de statut, les percentiles de latence (p50, p75, p95, p99 et maximum), les requêtes par seconde et les octets transférés. Par défaut, un seuil n'arrête pas le test ; abortWhenErrorCount l'arrête après un nombre donné de contrôles en échec (vérifié le 21 octobre 2026). La page n'indique pas de code de sortie, c'est pourquoi l'exemple ci-dessus en renvoie un à partir du résultat. Notre guide des critères de réussite d'un test de charge aide à choisir les limites.

Quels protocoles NBomber peut-il tester ?

Tout protocole qu'une bibliothèque .NET sait parler, car NBomber ne fait que chronométrer le code que vous lui donnez. Des plugins prêts à l'emploi couvrent HTTP, WebSockets, MQTT et AMQP, plus une option WebBrowser.

La page de présentation décrit le framework comme indépendant du protocole, et la page de tarifs inclut ces plugins dans toutes les formules, y compris la gratuite. Cela couvre aussi les bases de données et les files de messages que vous appelez avec leurs propres clients .NET (vérifié le 21 octobre 2026). La contrepartie : en dehors des plugins, c'est à vous d'écrire et de maintenir le code client.

Comment répartir un test NBomber sur plusieurs machines ?

Avec NBomber Cluster : un Coordinator orchestre l'exécution et des Agents exécutent les scénarios, le tout via un broker de messages NATS. Cluster fait partie de la licence Enterprise.

La présentation du cluster décrit les rôles, et la page de licence précise que les développeurs peuvent l'essayer en local avec un Local Dev Cluster avant d'acheter ; la page du Local Dev Cluster le limite à 1 Coordinator et 2 Agents et arrête chaque exécution au bout d'une minute (vérifié le 21 octobre 2026). L'intégration Kubernetes de NBomber Studio, elle aussi réservée à Enterprise, met en place NATS et les pods Agent à votre place. Sans Cluster, un processus NBomber tourne sur une seule machine ; la page de configuration requise conseille 4 à 8 cœurs CPU pour une charge élevée.

LoadFocus, qui publie ce site, n'exécute pas de tests NBomber. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud.

Quels sont les points forts et les limites de NBomber ?

Il est solide pour les équipes .NET : les tests sont du code C# ou F#, n'importe quel client .NET devient un test de charge et les deux modèles de charge sont intégrés. Ses limites sont la licence d'entreprise, un écosystème à un seul langage et des exécutions distribuées payantes.

Les tests vivent à côté du code de l'application, avec le même IDE, les mêmes paquets et les mêmes revues de code.
Les seuils sont intégrés, et les asserts tournent dans les tests xUnit ou NUnit que vous avez déjà.
L'usage commercial demande une licence, même pour un seul développeur.
Les exécutions distribuées demandent Enterprise et un broker NATS.
Des testeurs sans culture .NET devront d'abord apprendre C# ou F#.

Quand choisir plutôt k6, Gatling ou JMeter ?

Choisissez un autre outil si votre équipe n'écrit pas en .NET, ou si le coût de la licence ne convient pas.

Choisissez k6 pour des scripts JavaScript et un outil open source sans frais de licence en entreprise : son dépôt est sous AGPL-3.0 (vérifié le 21 octobre 2026). LoadFocus exécute des scripts k6 depuis 25 régions cloud, mais lance les scénarios arrival-rate avec un nombre fixe d'utilisateurs. Choisissez Gatling pour un outil orienté code sur la JVM ; notre revue de Gatling le couvre. Choisissez JMeter si vos testeurs préfèrent une interface graphique ou si vous avez besoin de samplers JDBC, JMS ou LDAP sans extension. Le panorama des outils de test de charge open source les compare côte à côte.

FAQ

NBomber est-il gratuit pour un usage commercial ? Non. NBomber n'est gratuit que pour un usage personnel et académique. Une entreprise a besoin d'une licence Business à 1 500 $ par an ou d'une licence Enterprise à 2 500 $ par an.

Quelles versions de .NET NBomber prend-il en charge ? Il cible .NET Standard 2.1, il tourne donc sur .NET Core 3.0 et toutes les versions de .NET suivantes. La documentation recommande .NET 10.

LoadFocus peut-il exécuter des tests NBomber ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour faire tourner NBomber sur plusieurs machines, utilisez NBomber Cluster, qui demande une licence Enterprise.

Test de charge Tsung : l'outil Erlang passé en revue

Wed, 21 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Tsung est un outil de test de charge open source écrit en Erlang, qui décrit chaque test dans un fichier XML et peut répartir la charge sur de nombreuses machines clientes. Le test de charge avec Tsung garde du sens pour des protocoles que peu d'outils couvrent, comme XMPP, LDAP ou PostgreSQL au niveau du protocole, et pour un très grand nombre d'utilisateurs sur du matériel modeste. La dernière version de Tsung date de mars 2023 : pour de nouveaux tests HTTP ou d'API, la plupart des équipes seront mieux servies par k6, Gatling ou JMeter.

Nous n'avons pas exécuté Tsung pour cette revue. Les faits proviennent de la documentation et du dépôt GitHub de Tsung, vérifiés le 21 octobre 2026, et les appréciations sont les nôtres.

Sujet	Tsung
Licence	GPL-2.0
Écrit en	Erlang (nécessite Erlang/OTP R16B03 ou plus récent)
Dernière version	1.8.0 (2 mars 2023)
Tests écrits en	Fichiers de configuration XML
Modèle de charge	Nouveaux utilisateurs par phase d'arrivée (ouvert)
Protocoles	HTTP, WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, TCP/UDP bruts (en partie expérimentaux)
Montée en échelle	Machines clientes via SSH sans mot de passe
Rapports	Tableau de bord en direct sur le port 8091, rapport HTML avec `tsung_stats.pl`

Qui maintient Tsung, et le projet est-il encore actif ?

ProcessOne héberge le projet sur GitHub sous GPL-2.0. Il est maintenu mais calme : la dernière version, la 1.8.0, date de mars 2023, et depuis il ne reçoit que des pull requests fusionnées de temps en temps.

Le dépôt affiche un dernier commit le 2 mars 2026, une pull request qui remplace des appels dépréciés, et le tag v1.8.0 est daté du 2 mars 2023 (vérifié le 21 octobre 2026). La documentation porte encore le titre 1.7.0 : vérifiez le dépôt quand un détail paraît daté. Un projet calme veut aussi dire moins de réponses quand quelque chose se passe mal.

Comment fonctionne un test Tsung ?

Un test est un fichier XML en quatre parties principales : les machines clientes, les serveurs cibles, les phases de charge et les sessions utilisateur. Chaque nouvel utilisateur choisit une session selon sa probabilité et exécute ses requêtes dans l'ordre.

Cet extrait lance cinq nouveaux utilisateurs par seconde pendant dix minutes ; chacun charge une liste de produits, marque une pause d'environ deux secondes puis envoie une requête POST au panier :

<load>
  <arrivalphase phase="1" duration="10" unit="minute">
    <users arrivalrate="5" unit="second"/>
  </arrivalphase>
</load>
<sessions>
  <session name="browse" probability="100"
           type="ts_http">
    <request><http url="/products" method="GET"/></request>
    <thinktime value="2" random="true"/>
    <request><http url="/cart" method="POST"
                   contents="sku=A-100"/></request>
  </session>
</sessions>

La page des sessions indique que les probabilités des sessions doivent totaliser 100 (ou, depuis la 1.5.0, que l'on peut utiliser des poids), et qu'un temps de réflexion aléatoire suit une loi exponentielle autour de sa valeur, sauf si vous donnez une plage min et max (vérifié le 21 octobre 2026). Pour HTTP et PostgreSQL, un enregistreur proxy transforme une session de navigateur ou de client en ce XML.

Quel modèle de charge Tsung utilise-t-il ?

Un modèle de charge ouvert. Chaque phase d'arrivée lance de nouveaux utilisateurs à intervalle ou à taux fixé, quoi que fassent les utilisateurs déjà en cours, et une phase se termine quand son temps est écoulé, même si ses sessions ne sont pas finies.

La page de la charge liste les réglages : interarrival ou arrivalrate par phase, maxnumber pour plafonner les utilisateurs lancés par une phase, un attribut duration sur l'ensemble de la charge pour arrêter le test à heure fixe, et wait_all_sessions_end pour que la phase suivante attende la fin des utilisateurs en cours (vérifié le 21 octobre 2026). Nos articles sur le modèle de charge ouvert ou fermé et sur le temps de réflexion expliquent comment ces choix changent ce que mesure un test.

Quels protocoles Tsung peut-il tester ?

Plus que la plupart des outils de test de charge : HTTP (y compris SOAP), WebDAV, XMPP, PostgreSQL, MySQL, LDAP, WebSocket, AMQP, MQTT, ainsi que TCP, UDP ou SSL bruts. La documentation qualifie d'expérimentaux les plugins MySQL, WebSocket, AMQP et MQTT, avec AMQP 0.9.1 et MQTT 3.1 seulement.

La page des fonctionnalités décrit chaque plugin (vérifié le 21 octobre 2026). Sur XMPP et PostgreSQL, Tsung a longtemps eu peu de concurrents : il parle lui-même le protocole, vous testez donc le serveur et non une bibliothèque cliente. Pour les applications temps réel, notre panorama des outils de test de charge WebSocket place Tsung à côté d'options plus récentes.

Comment répartir un test Tsung sur plusieurs machines ?

Vous listez les machines clientes dans le XML, et le contrôleur y lance la charge via SSH sans mot de passe, ou via rsh. Chaque client peut recevoir un poids, une limite d'utilisateurs et un nombre de CPU.

La page clients et serveur explique que Tsung fait tourner une machine virtuelle Erlang par CPU déclaré avec cpu sur chaque client (un seul par défaut) et en démarre une nouvelle quand une VM atteint maxusers. Il peut aussi récupérer ses machines clientes auprès d'un ordonnanceur de lots comme PBS, LSF ou OAR. La page d'installation demande Erlang/OTP R16B03 ou plus récent, plus, en option, Perl 5 et gnuplot, ou Python et matplotlib, pour les graphiques (vérifié le 21 octobre 2026).

LoadFocus, qui publie ce site, n'exécute pas de fichiers Tsung. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud.

Comment lire les résultats de Tsung ?

De deux façons : avec un tableau de bord en direct servi par le contrôleur sur le port 8091, et avec un rapport HTML généré après l'exécution par le script tsung_stats.pl.

La page des rapports indique que le tableau de bord existe depuis la 1.6.0, montre l'état courant, construit les graphiques pendant le test et s'arrête à la fin du test, sauf si vous lancez Tsung avec -k (vérifié le 21 octobre 2026). Le rapport couvre les temps de réponse et de connexion, les transactions, les requêtes par seconde et les codes d'erreur, et peut inclure les mesures CPU, mémoire et réseau des serveurs, collectées par des agents Erlang, SNMP ou munin. La documentation ne décrit pas de seuil de réussite : un pipeline CI doit analyser lui-même les résultats ; notre guide des critères de réussite d'un test de charge dit quoi vérifier.

Quels sont les points forts et les limites de Tsung ?

Il est solide sur l'étendue des protocoles, les phases d'arrivée ouvertes et le nombre d'utilisateurs par machine, que la documentation chiffre en milliers par CPU. Ses limites sont un historique de versions calme, des scripts uniquement en XML et aucun contrôle de réussite intégré.

Tests XMPP, LDAP et bases de données au niveau du protocole, sans écrire de code client.
Répartition par simple SSH, sans broker ni service supplémentaire.
Supervision des serveurs dans le même rapport.
Toute logique au-delà du XML passe par Erlang, que peu d'équipes écrivent.
Erlang doit être installé sur le contrôleur et sur chaque client.

Quand choisir plutôt k6, Gatling ou JMeter ?

Choisissez un autre outil si vous testez du HTTP ou des API et voulez un projet actif, avec des scripts dans un langage répandu.

Choisissez k6 pour des scripts JavaScript avec des seuils intégrés au script et un projet actif (vérifié le 21 octobre 2026). Choisissez Gatling pour des simulations orientées code sur la JVM ; notre revue de Gatling le couvre. Choisissez JMeter si vos testeurs veulent une interface graphique ou si vous avez besoin de samplers JDBC, JMS ou LDAP avec un large écosystème de plugins. LoadFocus exécute JMeter et k6 depuis 25 régions cloud, et le panorama des outils de test de charge open source compare ces outils côte à côte.

FAQ

Tsung est-il encore maintenu ? Oui, mais discrètement. La dernière version, la 1.8.0, est sortie le 2 mars 2023, et le dépôt reçoit encore de temps en temps des changements fusionnés, le dernier en mars 2026.

Quels protocoles Tsung prend-il en charge ? HTTP et SOAP, WebDAV, XMPP, PostgreSQL, LDAP et TCP, UDP ou SSL bruts, plus MySQL, WebSocket, AMQP et MQTT, que la documentation qualifie d'expérimentaux.

LoadFocus peut-il exécuter des tests Tsung ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour répartir un test Tsung sur plusieurs machines, listez-les comme clients dans le fichier XML.

Test de charge Artillery : l'outil Node.js passé en revue

Mon, 19 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Artillery est un outil de test de charge open source qui tourne sur Node.js et décrit chaque test dans un fichier YAML, TypeScript ou JavaScript. Le test de charge avec Artillery convient aux équipes qui vivent dans l'écosystème JavaScript, qui veulent faire arriver de nouveaux utilisateurs à un rythme fixé ou qui veulent des tests navigateur avec Playwright dans le même outil. Les équipes qui veulent un binaire unique sans runtime seront mieux servies par k6, et celles qui ont besoin de nombreux protocoles prêts à l'emploi par JMeter.

Nous n'avons pas exécuté Artillery pour cette revue. Les faits proviennent de la documentation, du dépôt, du paquet npm et de la page de tarifs d'Artillery, vérifiés le 19 octobre 2026, et les appréciations sont les nôtres.

Sujet	Artillery
Licence	MPL-2.0 ; certains modules Azure sous BSL
Runtime	Node.js, dernière LTS (le paquet exige 22.18.0 ou plus)
Version actuelle	2.0.34 (14 août 2026)
Tests écrits en	YAML, TypeScript ou JavaScript
Modèle de charge	Nouveaux utilisateurs virtuels par seconde, par phases
Moteurs intégrés	HTTP, WebSocket, Socket.IO, Playwright
Contrôles de réussite	Plugin `ensure`, code de sortie non nul
Montée en charge	`run-lambda`, `run-fargate`, `run-aci`
Rapports hébergés	Artillery Cloud, facultatif, avec offre gratuite

Qui développe Artillery, et sous quelle licence ?

Artillery Software Inc. le maintient sur GitHub. L'essentiel du code est sous MPL-2.0, qui autorise l'usage commercial ; certains modules propres à Azure sont sous Business Source License.

Le README du dépôt autorise l'usage d'Artillery sur Azure pour l'évaluation et les preuves de concept, et exige une licence commerciale pour un usage commercial ou en production sur Azure. La dernière version est la 2.0.34, publiée sur npm le 14 août 2026, et ses métadonnées demandent Node.js 22.18.0 ou plus ; le guide d'installation recommande la dernière version LTS (vérifié le 19 octobre 2026).

Comment fonctionne un script de test Artillery ?

Un script a deux parties : config, qui fixe la cible, les phases de charge et les plugins, et scenarios, qui liste ce que fait chaque utilisateur virtuel. Vous pouvez l'écrire en YAML ou exporter config et scenarios depuis un fichier TypeScript ou JavaScript.

Ce test monte de 5 à 50 nouveaux utilisateurs par seconde en deux minutes, tient 50 par seconde pendant dix minutes et échoue si le 99e percentile du temps de réponse atteint 800 ms :

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

D'après la référence des scripts de test, les quatre types de phase sont un taux d'arrivée constant, une rampe linéaire avec rampTo, un arrivalCount fixe réparti sur une période et une pause. Le code personnalisé chargé par config.processor peut être un module TypeScript en local et sur Fargate, pas sur Lambda (vérifié le 19 octobre 2026).

Quel modèle de charge Artillery utilise-t-il ?

Artillery lance de nouveaux utilisateurs virtuels au rythme que vous fixez, que les précédents aient terminé ou non. C'est un modèle de charge ouvert, qui maintient les arrivées même quand le système ralentit.

Chaque nouvel utilisateur choisit un scénario, l'exécute et repart, donc un système lent accumule des utilisateurs comme le ferait un vrai trafic. maxVusers plafonne le nombre d'utilisateurs simultanés d'une phase si vous devez protéger le générateur de charge. Notre article sur le modèle de charge ouvert ou fermé explique la différence, et la loi de Little montre comment le taux d'arrivée et le temps de réponse fixent le nombre d'utilisateurs simultanés.

Quels protocoles et navigateurs peut-il tester ?

HTTP est le moteur par défaut, et WebSocket, Socket.IO et Playwright sont intégrés. gRPC et AWS Kinesis demandent des moteurs installés à part.

La page des moteurs décrit le principe : chaque scénario tourne sur un moteur, et vous pouvez écrire le vôtre. Sur npm, artillery-engine-grpc en est à la 0.0.9 et artillery-engine-kinesis à la 1.1.1, tous deux sous MPL-2.0. Le moteur Playwright exécute votre code Playwright dans de vrais navigateurs headless et publie des Web Vitals comme TTFB, FCP et LCP par page. La documentation prévient qu'un navigateur séparé par utilisateur, au lieu d'un contexte de navigateur, demande beaucoup plus de CPU et de mémoire (vérifié le 19 octobre 2026). Notre panorama des outils de test de charge WebSocket place Artillery à côté d'autres options pour les applications temps réel.

Comment s'intègre-t-il à la CI ?

Le plugin ensure transforme des métriques en contrôles de réussite, et un contrôle en échec fait sortir Artillery avec un code non nul. Cela suffit à n'importe quel système de CI pour faire échouer le build.

La référence d'ensure propose deux types de contrôle : thresholds, où une métrique doit rester sous une valeur, et conditions, qui combinent des métriques dans une expression comme http.response_time.p95 < 250 and http.request_rate > 1000. Une condition marquée strict: false signale sans faire échouer. Le plugin apdex ajoute un score Apdex aux tests HTTP, avec un seuil par défaut de 500 ms (vérifié le 19 octobre 2026) ; notre article sur le score Apdex explique comment le lire. Pour un fichier de workflow, voir notre guide du test de charge dans GitHub Actions.

Comment faire monter un test Artillery en charge ?

Depuis la ligne de commande, sur votre propre compte cloud : run-lambda et run-fargate sur AWS, run-aci sur Azure Container Instances. Artillery crée les ressources nécessaires à l'exécution et supprime ensuite les ressources temporaires.

Le guide Fargate liste les ressources et les permissions IAM en jeu. Le guide Lambda en donne les limites : un test ne peut pas durer plus de 15 minutes, un test lancé ne peut pas être arrêté, et les hooks before et after tournent une fois par worker. Le guide Azure demande Artillery 2.0.19 ou plus et, hors évaluation, un abonnement (vérifié le 19 octobre 2026).

LoadFocus, qui publie ce site, n'exécute pas de scripts Artillery. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud : pour Artillery, les commandes ci-dessus restent le moyen de monter en charge.

Combien coûte Artillery Cloud ?

Le tableau de bord est facultatif : les résultats n'y arrivent que si vous lancez avec --record et une clé d'API. Les offres vont d'une formule gratuite à 499 $ par mois.

La page de tarifs indique (vérifié le 19 octobre 2026) :

Free : 30 rapports par mois, 1 mois de conservation, 2 membres, tests distribués jusqu'à 5 workers et 30 minutes.
Team, 199 $ par mois : 1 000 rapports, 6 mois, 8 membres, jusqu'à 25 workers et 2 heures.
Business, 499 $ par mois : 2 500 rapports, 18 mois, sans limite de membres, de workers ni de durée.

Le SSO entreprise, les journaux d'audit et les SLA de support commencent à 1 199 $ par mois, et la facturation annuelle fait économiser 20 %.

Que fait bien Artillery, et où sont ses limites ?

Il excelle sur la charge à taux d'arrivée, les scripts courts et lisibles et les tests navigateur avec Playwright. Il est moins à l'aise quand il faut un binaire unique, de nombreux protocoles sans extension ou Azure sans licence.

En tant qu'outil Node.js, il peut utiliser n'importe quel module npm dans des fonctions personnalisées, au prix d'un runtime de plus sur chaque machine de test. Limites que la documentation énonce elle-même :

Les exécutions Lambda s'arrêtent à 15 minutes et ne peuvent pas être annulées.
Le code personnalisé en TypeScript (config.processor) ne tourne pas sur Lambda.
gRPC et Kinesis sont des moteurs séparés.
L'usage en production sur Azure exige une licence commerciale.

Quand choisir plutôt k6, JMeter ou Locust ?

Choisissez un autre outil quand son runtime, ses protocoles ou son langage conviennent mieux à votre équipe.

Choisissez plutôt k6 si vous voulez un binaire Go sans Node.js à gérer et des seuils dans le script. Notre comparatif k6 vs Artillery met les deux côte à côte. LoadFocus exécute des scripts k6 depuis 25 régions cloud, mais fait tourner les scénarios arrival-rate avec un nombre fixe d'utilisateurs ; pour tenir un taux d'arrivée, lancez-les avec k6 lui-même.

Choisissez plutôt JMeter si vous avez besoin de JDBC, JMS, LDAP ou FTP prêts à l'emploi, ou si vos testeurs construisent leurs tests dans une interface graphique.

Choisissez plutôt Locust si votre équipe écrit en Python ; notre revue de Locust le présente. Le panorama des outils de test de charge open source les met tous côte à côte.

FAQ

Artillery est-il gratuit pour un usage commercial ? La CLI est en majeure partie sous MPL-2.0, qui autorise l'usage commercial. L'exception est Azure : un usage commercial ou en production de ses modules Azure exige une licence commerciale.

Artillery peut-il exécuter des tests navigateur ? Oui. Son moteur Playwright intégré exécute votre code Playwright dans des navigateurs headless et publie des Web Vitals pour chaque page.

LoadFocus peut-il exécuter des scripts Artillery ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour faire monter un test Artillery en charge, utilisez run-lambda, run-fargate ou run-aci.

Score Apdex : définition et méthode de calcul

Mon, 19 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Un score Apdex est un nombre entre 0 et 1 qui indique la part des requêtes assez rapides pour les personnes qui les attendent. Vous choisissez un temps cible T : les réponses jusqu'à T comptent entièrement, celles jusqu'à quatre fois T comptent pour moitié, et les plus lentes comptent zéro. Un résultat de 1 signifie que chaque requête a atteint la cible, et 0 que chacune était trop lente.

Zone	Temps de réponse	Poids dans le score
Satisfait (satisfied)	jusqu'à T	1
Tolérant (tolerating)	au-delà de T, jusqu'à 4T	0,5
Frustré (frustrated)	au-delà de 4T	0

Les faits ci-dessous viennent de la documentation et du code source des outils, vérifiés le 19 octobre 2026.

Comment calculer un score Apdex ?

Additionnez les requêtes satisfaites et la moitié des requêtes tolérées, puis divisez par le total. Le résultat tombe toujours entre 0 et 1.

Apdex(T) = (satisfied + tolerating / 2) / total

La documentation Apdex de New Relic déroule un exemple avec T fixé à 500 ms : sur 200 requêtes, 170 se terminent en 500 ms au plus, 20 prennent entre 500 ms et 2 secondes, et 10 échouent ou prennent plus longtemps. Cela donne (170 + 20 / 2) / 200 = 0,90 (vérifié le 19 octobre 2026).

Un second exemple montre l'intérêt du score en test de charge. Une exécution envoie 10 000 requêtes avec T = 300 ms : 8 200 se terminent en 300 ms, 1 300 entre 300 ms et 1,2 seconde, et 500 prennent plus longtemps. L'Apdex vaut (8 200 + 650) / 10 000 = 0,885. La même exécution peut très bien afficher une moyenne de 280 ms, qui semble correcte seule et masque les 500 requêtes de plus d'une seconde.

D'où vient l'Apdex ?

Apdex, pour Application Performance Index, est un standard ouvert né d'un groupe d'entreprises, l'Apdex Alliance. Peter Sevcik, de NetForecast, a fondé l'Alliance en 2004.

L'article Wikipédia sur l'Apdex cite l'article de Sevcik de 2005 et donne la règle des 4T. L'Apdex Users Group indique aujourd'hui que les règles des seuils T et F « sont devenues flexibles » (vérifié le 19 octobre 2026), et les outils profitent de cette liberté.

Comment JMeter, Artillery et LoadFocus le calculent-ils ?

Tous trois partent de T = 500 ms. Ils diffèrent sur la fin de la zone tolérée et sur le sort des requêtes en échec, si bien qu'une même exécution peut donner trois valeurs un peu différentes.

Outil	T par défaut	Toléré jusqu'à	Requêtes en échec
Tableau de bord HTML de JMeter	500 ms	1 500 ms	comptées comme frustrées
Plugin `apdex` d'Artillery	500 ms	4T (2 000 ms)	seules les réponses sont notées
Page de résultats LoadFocus	500 ms, fixe	4T (2 000 ms)	classées selon le temps de réponse
New Relic APM	réglé par application	4T	erreurs serveur frustrées

JMeter. Le rapport de tableau de bord contient un tableau APDEX par transaction. Ses valeurs par défaut sont jmeter.reportgenerator.apdex_satisfied_threshold=500 et apdex_tolerated_threshold=1500 : la zone tolérée s'arrête donc à 3T tant que vous n'y touchez pas, et apdex_per_transaction fixe des seuils propres à chaque sampler. Dans ApdexSummaryConsumer, un échantillon en échec s'ajoute au total et jamais aux satisfaits ou aux tolérés, donc chaque échec fait baisser le score (vérifié le 19 octobre 2026).

Artillery. Le plugin apdex ne fonctionne qu'avec le moteur HTTP et publie les compteurs apdex.satisfied, apdex.tolerated et apdex.frustrated. Son code dans artillery-plugin-apdex 1.24.0 classe chaque réponse selon son temps total par rapport à T et 4T, puis affiche le score avec une étiquette : excellent à partir de 0,94, good à partir de 0,85, fair à partir de 0,70, poor à partir de 0,49, unacceptable en dessous. Une requête qui ne reçoit jamais de réponse n'est jamais classée (vérifié le 19 octobre 2026). Notre revue d'Artillery présente l'outil lui-même.

LoadFocus, qui publie ce site, affiche le score Apdex dans l'onglet Insights d'un résultat de test de charge, à côté d'un histogramme des temps de réponse. T est fixé à 500 ms et la zone tolérée s'arrête à 2 000 ms ; T n'est pas modifiable. Chaque échantillon est classé selon son temps de réponse, et les parts satisfaite, tolérée et frustrée s'affichent à côté du score.

Comment choisir le seuil T ?

Choisissez T d'après ce qu'attendent les utilisateurs de cette page ou de cet endpoint, et réglez-le par transaction quand votre outil le permet. Un seul T pour toute une application mélange un endpoint de recherche rapide et un export de rapport lent dans un même chiffre.

Quelques règles pratiques :

Partez d'un objectif réel. Si vous avez déjà un objectif de latence comme « 95 % des appels de paiement sous 400 ms », T = 400 ms fait raconter la même histoire à l'Apdex et à l'objectif.
Gardez le même T d'une exécution à l'autre. Un Apdex ne se compare qu'à un Apdex mesuré au même T. Écrivez Apdex(0.4) ou « Apdex à T = 400 ms » pour éviter les comparaisons entre seuils différents.
Alignez aussi la zone tolérée. Le réglage par défaut de JMeter s'arrête à 3T et les autres à 4T. Avant de comparer un rapport JMeter avec un autre outil, réglez apdex_tolerated_threshold sur quatre fois T.
N'ajustez pas T pour faire passer une version. Déplacer T après une mauvaise exécution change la règle graduée, et la tendance que vous suiviez disparaît.

Qu'est-ce qu'un bon score Apdex ?

Le plugin d'Artillery qualifie de excellent 0,94 et plus, de good 0,85 à 0,94, et de poor ou pire tout ce qui passe sous 0,70. Ces étiquettes n'ont de sens que si T a été choisi honnêtement.

Un Apdex de 0,95 à T = 2 secondes peut décrire un service plus lent qu'un 0,80 à T = 200 ms. Quand vous fixez un critère de mise en production, écrivez le seuil et le score ensemble (« Apdex(0.5) d'au moins 0,9 ») et vérifiez-le à côté d'une limite de percentile, car les deux repèrent des problèmes différents.

Que cache l'Apdex ?

Il réduit toute la distribution des temps de réponse à trois cases, il ne peut donc pas dire à quel point les requêtes frustrées étaient lentes. Une requête à 2,1 secondes et une autre à 30 secondes font baisser le score exactement autant.

C'est pourquoi il fonctionne mieux accompagné d'autres chiffres :

Les percentiles montrent la lenteur des requêtes lentes. Notre guide sur la latence de queue explique pourquoi le 99e percentile compte dès qu'une page appelle plusieurs services.
Le taux d'erreur repère les échecs que votre outil ne note peut-être pas. Artillery ne note jamais les requêtes sans réponse et New Relic compte les erreurs serveur comme frustrées : lisez le nombre d'erreurs à part.
La taille de l'échantillon compte : New Relic précise que sous environ 100 requêtes par minute, le score est instable.
Le biais de mesure existe aussi. Un générateur de charge qui attend les réponses lentes envoie moins de requêtes pendant les périodes lentes, et l'Apdex paraît meilleur que la réalité ; voir la coordinated omission.

Comment utiliser l'Apdex dans un test de charge ?

Servez-vous-en comme résumé pour ceux qui ne liront pas un histogramme, et gardez la décision de réussite ou d'échec sur des limites explicites.

Une routine qui fonctionne :

Fixez T pour chaque transaction clé d'après votre objectif de latence.
Lancez le test et notez l'Apdex à ce T, ainsi que les 95e et 99e percentiles et le taux d'erreur.
Comparez l'Apdex avec l'exécution précédente au même T. Une baisse de 0,93 à 0,86 est un signal clair, même pour quelqu'un d'extérieur à l'équipe.
Faites échouer le build sur les limites de percentile et d'erreur, comme décrit dans notre guide sur les critères de réussite d'un test de charge, et publiez l'Apdex à côté.

FAQ

Un score Apdex plus élevé est-il meilleur ? Oui. 1,0 signifie que chaque requête s'est terminée en T au plus, et 0 que chacune a dépassé la limite tolérable ou a été comptée comme frustrée.

Quel est le seuil Apdex par défaut dans JMeter ? Le tableau de bord HTML utilise 500 ms pour satisfait et 1 500 ms pour toléré. Modifiez-les avec jmeter.reportgenerator.apdex_satisfied_threshold et apdex_tolerated_threshold.

L'Apdex tient-il compte des erreurs ? Cela dépend de l'outil. JMeter compte les échantillons en échec comme frustrés et New Relic fait de même avec les erreurs serveur, alors que le plugin d'Artillery ne note que les requêtes qui ont reçu une réponse.

Peut-on comparer les scores Apdex de deux outils ? Seulement si T, la limite tolérable et le traitement des erreurs sont identiques. Sinon, comparez plutôt les percentiles et les taux d'erreur sous-jacents.

Azure Load Testing : le service de Microsoft passé en revue

Mon, 19 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Azure Load Testing est le service managé de Microsoft pour exécuter des tests JMeter et Locust à grande échelle depuis Azure, facturé à l'heure d'utilisateur virtuel. Il convient bien quand le système testé tourne sur Azure, car il peut récupérer les métriques serveur d'Azure Monitor et atteindre des endpoints privés dans un réseau virtuel. Les équipes qui écrivent des scripts k6, qui n'ont pas d'abonnement Azure ou qui testent depuis l'extérieur des régions Azure trouveront d'autres services plus simples.

Nous n'avons pas exécuté Azure Load Testing pour cette revue. Les faits proviennent de la documentation et de la page de tarifs de Microsoft, vérifiées le 19 octobre 2026, et les appréciations sont les nôtres.

Sujet	Azure Load Testing
Type	Service managé du hub Azure App Testing
Frameworks de test	Apache JMeter et Locust uniquement
Option sans code	Test rapide par URL, jusqu'à cinq requêtes HTTP
Échelle par exécution	Jusqu'à 400 instances de moteur
Test le plus long	24 heures
Origine de la charge	Région de la ressource, ou jusqu'à 5 régions
Endpoints privés	Oui, par injection dans un réseau virtuel
Prix	0,15 $ par heure d'utilisateur virtuel, 0,06 $ après 10 000
Conservation	6 mois ; métriques client 365 jours

Qu'est-ce qu'Azure Load Testing ?

C'est un service entièrement managé qui exécute votre test de charge sur les moteurs de test de Microsoft, si bien que vous ne construisez ni ne maintenez jamais de générateurs de charge. Vous créez une ressource de test de charge dans une région Azure, vous y ajoutez des tests et vous lancez les exécutions depuis le portail, l'Azure CLI ou un pipeline.

La page de présentation précise que l'application testée peut se trouver n'importe où : dans Azure, sur site ou dans un autre cloud. Microsoft range désormais le service dans le hub Azure App Testing, à côté de Playwright Workspaces ; le démarrage rapide Locust crée la ressource depuis ce hub (vérifié le 19 octobre 2026).

Quels types de tests et quels outils prend-il en charge ?

Trois entrées : un test rapide par URL, un script JMeter téléversé ou un script Locust téléversé. La documentation indique clairement qu'aucun autre framework de test n'est pris en charge.

Le test rapide accepte jusqu'à cinq requêtes HTTP et un nombre cible d'utilisateurs virtuels ou de requêtes par seconde. Chaque moteur gère jusqu'à 250 utilisateurs virtuels, donc 400 utilisateurs tournent sur deux moteurs de 200 chacun.

Avec JMeter, vous pouvez utiliser des plugins de jmeter-plugins.org ou téléverser les vôtres, et la présentation affirme que tous les protocoles pris en charge par JMeter fonctionnent, comme une connexion à une base de données ou une file de messages. Avec Locust, vous pouvez ajouter des plugins Locust et d'autres bibliothèques Python. La documentation de Locust renvoie elle-même vers le service comme option hébergée, et notre revue de Locust présente l'outil lui-même. Les scripts k6, Gatling et Artillery ne tournent pas ici (vérifié le 19 octobre 2026).

Comment fonctionnent moteurs, utilisateurs virtuels et limites ?

Vous faites monter un test en charge en ajoutant des instances de moteur. Pour JMeter, la charge totale est le nombre d'utilisateurs du plan de test multiplié par le nombre de moteurs ; pour Locust, vous fixez le total d'utilisateurs et choisissez combien de moteurs les génèrent.

La page des concepts donne les deux formules, et la page des limites du service fixe les plafonds par région et par abonnement (vérifié le 19 octobre 2026) :

Instances de moteur par exécution : 1 à 400 par défaut selon l'offre, 400 au maximum.
Instances de moteur simultanées : 5 à 400 par défaut, jusqu'à 1 000 sur demande.
Durée de test : 3 à 24 heures par défaut, 24 heures au maximum.
Critères d'échec : jusqu'à 50 par test.
Conservation : métriques serveur 90 jours, métriques client 365 jours, résultats et journaux 6 mois.

Relever une limite par défaut passe par une demande au support ; rien ne dépasse les maximums indiqués.

Peut-il tester des endpoints privés et générer de la charge depuis plusieurs régions ?

Oui aux deux, avec une réserve : les deux ne se combinent pas. La charge multirégion ne fonctionne que vers des endpoints publics.

Par défaut, les moteurs tournent dans la région de votre ressource de test de charge. Le guide multirégion permet de choisir jusqu'à 5 régions par test et d'y répartir la charge, et il bascule alors le test en trafic public. Pour les services sans endpoint public, l'injection dans un réseau virtuel place les moteurs dans le réseau qui héberge l'application (vérifié le 19 octobre 2026).

Que montrent les résultats et les métriques serveur ?

Le tableau de bord affiche en direct les métriques côté client pendant l'exécution, comme les utilisateurs virtuels, le temps de réponse et les requêtes par seconde. Pour les applications hébergées sur Azure, il ajoute les métriques côté serveur d'Azure Monitor, d'Application Insights et de Container Insights sur la même chronologie.

Ce couplage est le principal atout du service : vous voyez la base de données ou le conteneur qui sature au moment où les temps de réponse montent, sans monter un tableau de bord séparé. Le guide des métriques serveur en décrit les étapes. Les exécutions passées restent comparables côte à côte, et vous pouvez télécharger les résultats pour d'autres outils.

Comment fonctionnent les critères de réussite et la CI ?

Vous définissez des critères d'échec sur des métriques client ou serveur, et l'exécution est marquée en échec dès que l'un d'eux est dépassé. Les pipelines d'Azure DevOps, de GitHub Actions ou de tout outil de CI capable d'appeler l'Azure CLI peuvent lancer un test et faire dépendre la suite de ce résultat.

Selon le guide des critères d'échec, un critère est un agrégat d'une métrique client, comme le temps de réponse moyen ou le pourcentage d'erreurs, comparé à un seuil, soit pour tout le test, soit pour une requête nommée. Les métriques serveur exigent que l'identité managée de la ressource puisse les lire. L'arrêt automatique stoppe une exécution quand le taux d'erreur dépasse une limite, pour qu'une mauvaise URL ne continue pas à coûter. Le guide CI/CD couvre GitHub Actions et Azure Pipelines (vérifié le 19 octobre 2026). Notre guide sur les critères de réussite d'un test de charge explique comment choisir les limites.

Combien coûte Azure Load Testing ?

Vous payez à l'heure d'utilisateur virtuel (VUH) : 0,15 $ par VUH pour les 10 000 premières, puis 0,06 $ par VUH, au même tarif dans toutes les régions de la page de tarifs. Depuis le 1er mars 2026, il existe aussi un minimum facturé par exécution.

La page de tarifs définit une VUH comme le nombre d'utilisateurs virtuels multiplié par les minutes, divisé par 60, compté toutes les 10 secondes ; 1 000 utilisateurs pendant 30 minutes font 500 VUH, soit 75 $ au tarif du premier palier. Le minimum est de 10 utilisateurs virtuels par moteur pendant la durée de l'exécution, avec au moins 10 minutes. Une exécution de 3 heures avec 5 utilisateurs sur un moteur est donc facturée 30 VUH au lieu de 15 (vérifié le 19 octobre 2026).

Quand choisir autre chose ?

Choisissez une autre option quand vos scripts, votre cloud ou votre budget vous orientent ailleurs.

Notre panorama des outils de test de charge open source présente les outils que vous pouvez faire tourner vous-même.

Choisissez plutôt LoadFocus, qui publie ce site, si vous voulez exécuter des plans de test JMeter et des scripts k6 depuis 25 régions cloud sans abonnement Azure. LoadFocus n'exécute pas Locust et fait tourner les scénarios k6 arrival-rate avec un nombre fixe d'utilisateurs.

Choisissez plutôt Grafana Cloud k6 ou le k6-operator si vos tests sont écrits pour k6, qu'Azure Load Testing ne sait pas exécuter (vérifié le 19 octobre 2026).

Choisissez plutôt Locust auto-hébergé si vous disposez déjà de Kubernetes ou de machines libres : son mode distribué est gratuit, et vous ne payez que le matériel.

FAQ

Azure Load Testing prend-il en charge k6 ? Non. Il exécute des tests Apache JMeter et Locust, ainsi que des tests rapides par URL qu'il transforme lui-même en script. Les scripts k6 demandent un autre service ou votre propre infrastructure.

Puis-je utiliser Azure Load Testing pour une application qui n'est pas hébergée sur Azure ? Oui. Les moteurs de test peuvent viser n'importe quel endpoint public. Les métriques serveur ne sont collectées que pour les ressources Azure ; pour un autre hébergement, lisez les métriques serveur dans votre propre monitoring.

Existe-t-il une offre gratuite ? La page de tarifs n'indique pour le test de charge que des prix à l'heure, avec un minimum par exécution. Les nouveaux comptes Azure reçoivent un crédit de 200 $ pour leurs 30 premiers jours, d'après la même page.

Latence de queue : définition et mesure sous charge

Mon, 19 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

La latence de queue est le temps de réponse des quelques requêtes les plus lentes, généralement exprimé par le 99e ou le 99,9e percentile. Elle compte parce qu'une action d'utilisateur attend souvent de nombreuses requêtes : un retard qui touche 1 requête sur 100 peut alors atteindre la plupart de vos utilisateurs. Un test de charge qui n'affiche que la moyenne ou la médiane ne la montre pas.

Appels backend par page	Part des pages qui subissent au moins un appel lent (1 sur 100)
1	1,0 %
5	4,9 %
10	9,6 %
20	18,2 %
50	39,5 %
100	63,4 %

Le tableau suppose que chaque appel est lent avec 1 % de probabilité, indépendamment des autres : la part vaut 1 - 0.99^n.

Qu'appelle-t-on la queue ?

La queue est la partie de la distribution des temps de réponse située au-delà d'un percentile élevé, le plus souvent p99 et p99,9. La médiane décrit une requête typique, la queue décrit les requêtes dont les gens se plaignent.

Un percentile est un seuil : p99 = 800 ms signifie que 99 % des requêtes ont pris 800 ms ou moins et 1 % plus longtemps. Sur un histogramme des temps de réponse, la queue se trouve à droite de ce seuil, souvent sous la forme d'une longue traîne fine loin du pic principal. Notre guide débit vs latence explique comment les outils de test de charge mesurent la latence et les percentiles.

Pourquoi la latence de queue compte-t-elle autant ?

Parce que les requêtes se multiplient. Une page ou un appel d'API qui se répartit sur de nombreux services ne se termine que lorsque le plus lent a répondu, et la queue de chaque service devient l'expérience habituelle de l'ensemble.

La référence est « The Tail at Scale » de Jeffrey Dean et Luiz André Barroso, publié dans Communications of the ACM en 2013 (PDF de l'article, vérifié le 19 octobre 2026). Leur exemple : un serveur qui répond d'habitude en 10 ms mais met une seconde au 99e percentile. Si une requête touche un seul de ces serveurs, 1 requête d'utilisateur sur 100 est lente. Si elle doit rassembler les réponses de 100 serveurs en parallèle, 63 % des requêtes d'utilisateurs dépassent une seconde. Même avec un seul appel lent sur 10 000, un service de 2 000 serveurs voit près d'une requête sur cinq dépasser une seconde.

Ils citent aussi des mesures d'un vrai service de Google : le 99e percentile d'une seule requête feuille était de 10 ms, mais il atteignait 140 ms pour que toutes les requêtes feuilles se terminent, et l'attente des 5 % les plus lentes en représentait la moitié.

Qu'est-ce qui cause la latence de queue ?

Le plus souvent, des interférences dues à d'autres tâches sur la machine ou dans le réseau. La même requête est rapide la plupart du temps et lente quand il se passe autre chose.

Dean et Barroso citent les suspects habituels :

Ressources partagées : d'autres tâches sur la même machine qui se disputent les cœurs CPU, les caches du processeur, la bande passante mémoire ou réseau.
Démons en arrière-plan qui se réveillent et prennent une part de la machine.
Tâches de maintenance comme le compactage de journaux ou le garbage collection des environnements managés.
Files d'attente dans les serveurs et les commutateurs réseau, qui amplifient toutes les autres sources.
Limites de puissance et de température qui ralentissent un CPU après un pic de travail.

En test de charge, la même liste prend la forme de pauses GC dans des services JVM ou Node.js, d'un pool de connexions épuisé, d'une requête SQL lente que seules certaines requêtes déclenchent, de caches froids après un déploiement et de nouvelles tentatives après un timeout. Une queue qui grandit avec la charge indique des files d'attente ; une queue présente même à faible charge indique quelque chose de périodique, comme le GC ou une tâche planifiée.

Comment mesurer la latence de queue dans un test de charge ?

Collectez assez d'échantillons, demandez à votre outil les bons percentiles et ne faites jamais la moyenne de percentiles entre machines ou fenêtres de temps.

Assez d'échantillons. Le p99 dépend du 1 % de requêtes le plus lent : une exécution de 500 requêtes le fait donc reposer sur 5 d'entre elles. Pour un p99 stable, il faut des milliers de requêtes par transaction, et des dizaines de milliers pour le p99,9. Les tests de fumée courts sont utiles pour repérer des erreurs et peu fiables pour juger la queue.

Les bons percentiles. Les réglages par défaut s'arrêtent souvent avant la queue. Dans k6, summaryTrendStats vaut par défaut avg,min,med,max,p(90),p(95), donc le p99 n'apparaît que si vous l'ajoutez (référence des options k6, vérifiée le 19 octobre 2026) :

k6 run --summary-trend-stats="med,p(95),p(99),p(99.9),max" \
  script.js

L'Aggregate Report de JMeter affiche les lignes 90 %, 95 % et 99 %, et les propriétés aggregate_rpt_pct1 à aggregate_rpt_pct3 changent les percentiles affichés (vérifié le 19 octobre 2026).

Pas de moyenne de percentiles. Le p99 d'une exécution entière n'est ni la moyenne des p99 de chaque minute ni celle des p99 de chaque générateur de charge. Fusionnez les échantillons bruts ou un histogramme, puis calculez le percentile une seule fois. L'article sur la coordinated omission présente HdrHistogram, l'outil habituel pour cela, et un second piège : un générateur qui attend les réponses lentes envoie moins de requêtes pendant que le système ralentit, ce qui masque justement la queue que vous cherchez.

LoadFocus, qui publie ce site, affiche pour chaque exécution des tuiles P95 et P99, un histogramme des temps de réponse construit à partir des échantillons individuels et les requêtes les plus lentes : une longue traîne à droite du pic se voit d'un coup d'œil.

Comment fixer une limite de réussite sur la queue ?

Placez une limite sur le p99 pour chaque transaction clé, à côté d'une limite de p95 et d'une limite de taux d'erreur. Fondez-la sur les besoins des utilisateurs de cette transaction, et faites durer l'exécution assez longtemps pour que le p99 soit stable.

Un jeu raisonnable pour une API de paiement pourrait être : p95 sous 400 ms, p99 sous 1 200 ms, erreurs sous 0,5 %. Dans k6, ce sont des seuils sur http_req_duration comme p(99)<1200, et un seuil franchi fait sortir k6 avec un code différent de zéro (seuils k6, vérifié le 19 octobre 2026). LoadFocus propose un champ Max P99 response time à côté de Max P95 pour les tests cloud, JMeter et k6, et chaque exécution reçoit alors un PASS ou un FAIL. Notre guide sur les critères de réussite d'un test de charge couvre le reste du jeu.

Si vous publiez aussi un score Apdex, rappelez-vous qu'il range toute requête au-delà de quatre fois T dans une seule case et ne distingue donc pas une queue à 2 secondes d'une queue à 30 secondes. Le p99, si.

Comment réduire la latence de queue ?

Supprimez les sources de variabilité quand c'est possible, et concevez les appelants pour qu'un appel lent ne bloque pas toute la réponse.

Les correctifs courants, à peu près du moins coûteux au plus lourd :

Régler le GC et la taille des pools pour que les pauses et l'attente d'une connexion libre restent courtes sous charge.
Garder de la marge. Les files d'attente explosent près de la saturation, donc de la capacité libre raccourcit la queue ; le guide débit vs latence montre comment trouver le coude.
Fixer des timeouts et limiter les nouvelles tentatives pour qu'un appel bloqué échoue vite au lieu d'accumuler la file derrière lui.
Utiliser des requêtes couvertes (hedged requests) pour les lectures idempotentes : envoyer une seconde copie à un autre réplica si le premier n'a pas répondu à temps. Dean et Barroso décrivent l'envoi de la copie seulement après la latence attendue du 95e percentile, ce qui limite la charge supplémentaire à environ 5 %. Dans un de leurs tests, une copie envoyée après 10 ms a fait passer le 99,9e percentile de 1 800 ms à 74 ms, avec seulement 2 % de requêtes en plus.
Réduire le fan-out. Moins d'appels backend par page signifie moins de risques de tomber dans la queue, comme le montre le tableau du début.

Après chaque changement, relancez le même test avec le même profil de charge et comparez p99 et p99,9 d'une exécution à l'autre.

FAQ

La latence de queue est-elle la même chose que le p99 ? Le p99 est la façon la plus courante de l'exprimer, et la queue désigne toute l'extrémité lente de la distribution. Suivez aussi le p99,9 et le maximum quand l'exécution compte assez de requêtes.

Pourquoi mon p99 est-il tellement plus élevé que ma moyenne ? Parce que quelques requêtes lentes bougent à peine la moyenne et définissent entièrement le p99. Un grand écart est normal ; un écart qui grandit avec la charge signale en général des files d'attente.

Combien de requêtes faut-il pour mesurer le p99 ? Au minimum quelques milliers par transaction, pour que le p99 repose sur des dizaines de requêtes lentes. Pour le p99,9, prévoyez des dizaines de milliers.

Test de charge gRPC : outils, mise en place et mesures

Fri, 16 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Un test de charge gRPC demande un outil qui parle HTTP/2 et Protocol Buffers : k6 et ghz le font d'origine, JMeter a besoin d'un plugin, la prise en charge de gRPC dans Gatling est limitée dans son édition gratuite, et avec Locust vous devez intégrer vous-même un client gRPC. Comptez les résultats par statut gRPC, pas par statut HTTP, car les appels en échec arrivent quand même en HTTP 200, et vérifiez que la charge atteint chaque backend.

Aucun test gRPC n'a été exécuté pour cet article. Les faits sur les outils viennent de la documentation et des dépôts de chaque projet, vérifiés le 16 octobre 2026 ; les faits sur LoadFocus viennent de son code.

Outil	Prise en charge de gRPC	Lit l'API depuis	Contrôle de la cadence
k6	Intégré (`k6/net/grpc`), appels unaires et streams	Fichiers `.proto` ou réflexion serveur	Exécuteurs arrival-rate
ghz	Outil en ligne de commande dédié à gRPC	`.proto`, protoset ou réflexion serveur	`--rps` et plannings de charge
JMeter	Plugin tiers (jmeter-grpc-request)	Un dossier de fichiers `.proto`	Thread Groups et timers
Gatling	Composant gRPC séparé ; édition gratuite limitée à 5 utilisateurs, 5 minutes	Code généré depuis les `.proto` avec protoc	Profils d'injection
Locust	Pas de client intégré ; en envelopper un et remonter les appels	Votre client gRPC Python	Temps d'attente, `constant_throughput`

Pourquoi gRPC demande-t-il un autre test de charge que REST ?

gRPC passe par HTTP/2, envoie des Protocol Buffers binaires au lieu de JSON, place le résultat d'un appel dans un trailer plutôt que dans le statut HTTP, et multiplexe de nombreux appels sur une seule connexion. Chacun de ces points change la façon d'écrire le test ou d'en lire les résultats.

L'article sur la répartition de charge gRPC énumère les caractéristiques de HTTP/2 qui comptent ici : un protocole binaire, de nombreuses requêtes multiplexées sur une connexion et la compression des en-têtes, avec par-dessus des messages Protobuf fortement typés (vérifié le 16 octobre 2026). Un outil qui n'envoie que du JSON sur HTTP/1.1 ne peut pas appeler une méthode gRPC : vérifiez d'abord la prise en charge du protocole.

Quel outil choisir ?

Prenez k6 si vous voulez des scénarios, des checks et des seuils écrits en code ; prenez ghz pour un benchmark rapide d'une méthode en ligne de commande. Tournez-vous vers JMeter, Gatling ou Locust quand votre équipe y fait déjà tout le reste.

k6. Le module k6/net/grpc charge les définitions Protobuf, se connecte, fait des appels unaires avec invoke et ouvre des streams. Il rapporte grpc_req_duration et le nombre de messages des streams dans ses métriques.
ghz. Un outil de benchmark en ligne de commande réservé à gRPC. Ses options incluent --rps, --concurrency, --total et --duration, et si vous ne passez ni --proto ni --protoset, il tente la réflexion serveur. La dernière version est v0.121.0 (vérifié le 16 octobre 2026).
JMeter. Le cœur de JMeter n'a pas de sampler gRPC ; le plugin jmeter-grpc-request en ajoute un qui lit un dossier de fichiers .proto, sans génération de code (dernier tag v1.2.6, vérifié le 16 octobre 2026).
Gatling. Le README de Gatling place gRPC, MQTT et GraphQL sous la Gatling Enterprise Component License, limités en Community Edition à 5 utilisateurs simultanés et à des tests de 5 minutes (vérifié le 16 octobre 2026). Son guide de mise en place gRPC génère du code à partir de vos fichiers .proto avec protoc.
Locust. Sa documentation sur le test d'autres systèmes inclut un exemple gRPC : vous enveloppez un client gRPC pour que chaque appel soit remonté à Locust, et constant_throughput cadence une tâche à un nombre maximal d'exécutions par seconde.

Choisissez ghz plutôt que k6 quand vous voulez seulement savoir comment une méthode se comporte à une cadence donnée, sans écrire de script. Choisissez plutôt Locust quand votre équipe écrit en Python et que le test demande une logique plus simple à y écrire.

Comment écrire un test de charge gRPC avec k6 ?

Chargez le fichier .proto dans le code d'initialisation, puis, à chaque itération, connectez-vous, appelez la méthode et vérifiez le statut gRPC. La structure suit l'exemple de la documentation de k6.

import grpc from 'k6/net/grpc';
import { check } from 'k6';

const client = new grpc.Client();
client.load(['protos'], 'hello.proto');

export const options = { vus: 20, duration: '1m' };

export default () => {
  client.connect('grpc.example.com:443');
  const res = client.invoke('hello.Greeter/SayHello', {
    name: 'load test',
  });
  check(res, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
};

La page de invoke suit la même séquence : chargement, connexion, appel, vérification et fermeture. connect utilise TLS sauf si vous passez plaintext: true, et avec reflect: true il demande son API au serveur au lieu de lire un fichier .proto (paramètres de connexion). Pour tenir une cadence de requêtes plutôt qu'un nombre d'utilisateurs, exécutez la fonction dans un scénario arrival-rate.

Comment faire un benchmark rapide avec ghz ?

Indiquez à ghz la méthode, un corps de requête et une cadence ou un niveau de concurrence, et il affiche un histogramme de latence, des percentiles et un décompte par code de statut. Il convient pour un premier aperçu d'une méthode.

ghz --insecure --proto ./hello.proto \
  --call hello.Greeter.SayHello \
  -d '{"name":"load test"}' \
  --rps 200 -c 50 -z 1m \
  localhost:50051

--rps fixe la cadence visée, répartie entre les workers, -c le nombre de workers, et -z la durée. Retirez --proto pour laisser ghz utiliser la réflexion serveur, si le serveur l'active. La page sur la sortie de ghz montre un exemple de rapport.

Que mesurer dans un test de charge gRPC ?

Mesurez les percentiles de latence des appels, le débit et le nombre de chaque code de statut gRPC. Un taux de réussite au niveau HTTP peut afficher 100 % alors que des appels échouent, car le résultat voyage dans le trailer grpc-status.

La spécification gRPC sur HTTP/2 fixe le statut HTTP à :status 200 et transporte le résultat de l'appel dans des trailers, sous la forme grpc-status et grpc-message. La liste des codes de statut contient ceux qui comptent le plus sous charge :

DEADLINE_EXCEEDED (4) : l'échéance a expiré avant la fin de l'appel.
RESOURCE_EXHAUSTED (8) : un quota ou une ressource est épuisé.
INTERNAL (13) : un invariant interne est rompu, un code réservé aux erreurs graves.
UNAVAILABLE (14) : en général passager ; réessayer avec un backoff peut suffire, mais pas toujours sans risque pour les appels non idempotents.

Comptez chacun par palier de charge. Les erreurs d'échéance peuvent grimper alors que les appels réussis semblent encore rapides, parce que les appels lents sont coupés à l'échéance au lieu d'être enregistrés comme lents. Notre guide des critères de réussite d'un test de charge montre comment transformer ces décomptes en seuils.

Pourquoi toute la charge tombe-t-elle sur un seul serveur ?

Parce que gRPC multiplexe de nombreux appels sur une connexion de longue durée, un répartiteur qui travaille par connexion envoie chaque appel de celle-ci au même backend. Un générateur de charge avec peu de connexions peut alors saturer un serveur pendant que les autres restent inactifs.

L'article sur la répartition de charge gRPC explique le mécanisme. Un répartiteur au niveau transport (L3/L4) termine la connexion TCP et en ouvre une autre vers un backend choisi, en copiant les trames HTTP/2 et gRPC entre les deux ; un répartiteur au niveau applicatif (L7) analyse HTTP/2 et peut répartir les streams d'une même connexion cliente entre plusieurs backends. Si vos clients de production passent par un répartiteur L7 ou répartissent côté client, testez par le même chemin et surveillez le CPU et le nombre de requêtes de chaque backend pendant l'exécution.

Peut-on lancer des tests de charge gRPC sur LoadFocus ?

Pas d'une façon que ses rapports montreraient. LoadFocus exécute la version standard de k6 v0.57.0, qui inclut le module gRPC, mais son agent k6 ne transmet aux résultats que les mesures des requêtes HTTP : les appels gRPC généreraient de la charge sans apparaître dans ses graphiques ni dans ses décomptes d'erreurs.

Deux autres limites s'ajoutent. L'import de fichiers k6 accepte les fichiers .js, .ts, .csv, .txt, .json, .env et .properties, pas les fichiers .proto, donc un script devrait se connecter avec reflect: true. Et la voie JMeter est fermée : les agents JMeter de LoadFocus embarquent JMeter 5.6.2 avec des plugins préinstallés qui ne comprennent pas de sampler gRPC, et l'import JMeter n'accepte pas de fichiers JAR de plugin. Pour gRPC, lancez k6 ou ghz sur vos propres machines, et utilisez les scripts k6 sur LoadFocus pour la partie HTTP du même système, où il génère la charge depuis 25 régions.

FAQ

Peut-on tester en charge des appels gRPC en streaming ? Oui, avec k6 et ghz. Le module gRPC de k6 a une classe Stream avec write, end et des gestionnaires d'événements, et ghz a des options pour les intervalles et les durées de streaming. Mesurez les messages envoyés et reçus en plus de la latence des appels.

Faut-il le fichier .proto pour tester en charge un service gRPC ? Pas si le serveur active la réflexion. k6 peut se connecter avec reflect: true, et ghz se rabat sur la réflexion quand vous ne passez ni --proto ni --protoset. Sans réflexion, il vous faut le fichier .proto ou un protoset compilé.

Pourquoi mes erreurs gRPC n'apparaissent-elles pas comme des requêtes en échec ? Parce que le statut HTTP d'un appel gRPC vaut 200 même quand l'appel échoue. Le résultat se trouve dans le trailer grpc-status : vérifiez cette valeur dans votre script et comptez chaque code séparément.

Débit vs latence : comment ils interagissent sous charge

Fri, 16 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Le débit (throughput) est la quantité de travail qu'un système termine par unité de temps, par exemple des requêtes par seconde. La latence est le temps que prend une unité de travail, par exemple 120 millisecondes pour une requête. Sous une charge légère, les deux s'influencent à peine ; quand la charge approche la capacité du système, le débit cesse de monter et la latence se met à grimper, et trouver ce point est précisément le rôle d'un test de charge.

L'exemple chiffré ci-dessous est un simple calcul, sans test derrière. Les définitions des outils viennent de la documentation de chaque projet, vérifiée le 16 octobre 2026.

	Débit	Latence	Bande passante
Question posée	Combien se termine par seconde ?	Combien de temps prend une unité ?	Combien la liaison pourrait-elle porter ?
Unité habituelle	requêtes ou transactions par seconde	millisecondes	mégabits par seconde
Dans k6	`http_reqs` (nombre et taux)	`http_req_duration`	pas une cible de test
Dans JMeter	Throughput	Elapsed time (et une « Latency » distincte)	pas une cible de test

Quelle est la différence entre débit et latence ?

Le débit compte le travail terminé dans le temps ; la latence mesure le temps que prend une unité de travail. Un système peut avoir une faible latence et un faible débit, ou un débit élevé et une latence élevée : il faut donc les deux chiffres pour le décrire.

Le glossaire de JMeter calcule le débit comme le nombre de requêtes divisé par le temps total, du début du premier échantillon à la fin du dernier, pauses entre échantillons comprises, puisqu'il doit représenter la charge sur le serveur (vérifié le 16 octobre 2026). Le débit est donc une propriété de toute l'exécution, alors que la latence appartient à chaque requête et se lit mieux comme une distribution : médiane, p95, p99.

La bande passante est-elle la même chose que le débit ?

Non. La bande passante est la quantité maximale de données qu'une liaison réseau pourrait porter ; le débit est ce qui passe réellement. En test de charge, le débit désigne en général des requêtes terminées, et la bande passante ne compte que lorsque de gros volumes de données remplissent la liaison avant que l'application n'atteigne sa capacité.

La page de comparaison d'AWS résume la vision réseau : la latence est le délai dans la communication réseau, le débit le volume moyen de données qui passe réellement sur une période, et la bande passante le maximum théorique (vérifié le 16 octobre 2026). Une grande partie de ce que l'on trouve en ligne emploie ce sens réseau. Le test de charge utilise les mêmes mots pour des requêtes plutôt que pour des paquets, d'où l'intérêt de préciser lequel un rapport désigne.

Que signifie « latence » dans un outil de test de charge ?

Cela dépend de l'outil. Dans JMeter, Latency est le temps jusqu'à la première partie de la réponse, et le temps de réponse complet s'appelle Elapsed time. Dans k6, http_req_duration couvre l'envoi, l'attente et la réception, et le temps jusqu'au premier octet est une métrique à part.

Le glossaire de JMeter mesure l'Elapsed time de juste avant l'envoi de la requête à juste après la réception de la dernière réponse, et la Latency jusqu'à juste après la réception de la première. La référence des métriques de k6 définit http_req_duration comme http_req_sending + http_req_waiting + http_req_receiving, sans résolution DNS ni établissement de connexion, et appelle http_req_waiting le temps jusqu'au premier octet (les deux vérifiés le 16 octobre 2026). La Latency de JMeter correspond donc à http_req_waiting dans k6, pas à http_req_duration. Comparez une « latence » JMeter à une « duration » k6 et le chiffre de JMeter paraîtra meilleur sans l'être.

Comment le débit et la latence évoluent-ils quand la charge augmente ?

Au début, plus de charge signifie plus de débit, et la latence reste à peu près stable. Une fois le système à sa capacité, le débit ne progresse plus et chaque utilisateur supplémentaire n'ajoute que de l'attente : la latence monte avec la charge.

Un exemple chiffré, simple calcul. Un service traite au plus 200 requêtes par seconde et répond en 0,1 seconde quand il n'est pas chargé. Chaque utilisateur virtuel envoie une requête puis fait une pause de 1 seconde. Avec un nombre fixe d'utilisateurs, la forme de la loi de Little pour le modèle fermé relie les grandeurs : utilisateurs = requêtes par seconde × (latence + temps de réflexion), comme le montre pas à pas notre article sur la loi de Little.

Utilisateurs virtuels	Débit (requêtes/s)	Latence (s)
50	45	0,1
150	136	0,1
220	200	0,1
300	200	0,5
400	200	1,0
600	200	2,0

Jusqu'à 220 utilisateurs, le débit progresse au même rythme qu'eux. Ensuite il reste bloqué à 200, et la latence doit absorber le reste : 300 utilisateurs demandent 300 ÷ 200 = 1,5 seconde par boucle, ce qui laisse 0,5 seconde de latence. Les systèmes réels fléchissent en général plus progressivement, car des files d'attente se forment avant le plafond exact. Avec un test à taux d'arrivée, la situation est pire : si les requêtes arrivent à plus de 200 par seconde, l'arriéré grossit tant que dure l'excédent, ce que l'article sur le modèle de charge ouvert ou fermé explique.

Comment repérer le coude dans vos propres résultats ?

Augmentez la charge par paliers, maintenez chaque palier assez longtemps pour qu'il se stabilise, et notez le débit et un percentile de latence pour chacun. Le coude est le premier palier où le débit ne suit plus la charge alors que la latence commence à grimper.

Quelques précautions rendent cette lecture fiable :

Maintenez chaque palier quelques minutes, pour mesurer le débit sur une phase stable et non sur une rampe.
Lisez un percentile, pas seulement la moyenne ; une moyenne peut rester calme pendant que les quelques pour cent de requêtes les plus lentes ralentissent nettement.
Vérifiez les erreurs à chaque palier. Les échecs rapides comptent comme des requêtes terminées avec des temps courts, si bien qu'un système défaillant peut afficher un débit en hausse et une latence en baisse.
Surveillez le générateur de charge. Si son CPU sature, le plafond trouvé est peut-être le sien.

Le graphique temps de réponse face aux utilisateurs virtuels de LoadFocus trace le temps de réponse moyen et maximal en fonction des utilisateurs virtuels actifs, un point par palier atteint, et c'est là que le coude apparaît dans un test par paliers.

Peut-on augmenter le débit sans augmenter la latence ?

Parfois. Ajouter de la capacité déplace le plafond, si bien que la latence reste plate plus longtemps. Le regroupement (batching) fait en général le compromis inverse : il augmente le débit en faisant attendre chaque requête.

L'algorithme de Nagle de TCP est l'exemple classique de ce compromis. La RFC 896 retient les nouveaux segments tant que des données déjà envoyées sur la connexion ne sont pas acquittées, de sorte que le réseau transporte moins de paquets, plus pleins, et que chaque petite écriture peut attendre (vérifié le 16 octobre 2026). Le regroupement de requêtes et la mise en tampon des écritures fonctionnent de la même façon : plus de travail par seconde, plus de temps par élément. Quand vous modifiez l'un d'eux, relancez le test par paliers et comparez les deux courbes, pas un seul chiffre.

Lequel des deux mettre dans vos critères de réussite ?

Les deux, liés. Un objectif de latence veut peu dire sans le débit auquel il a été mesuré, et un objectif de débit veut peu dire si la latence a doublé pour l'atteindre. Formulez-les comme une paire, par exemple p95 sous 300 millisecondes à 200 requêtes par seconde avec moins de 1 % d'erreurs.

Notre guide des critères de réussite d'un test de charge montre comment écrire et automatiser cette paire. Si votre outil attend les réponses lentes avant d'envoyer la requête suivante, ses chiffres de latence peuvent minimiser le problème ; la coordinated omission explique comment cela arrive et comment l'éviter. L'entrée du glossaire LoadFocus sur la latence détaille d'où vient la latence et pourquoi les percentiles comptent.

FAQ

Une faible latence signifie-t-elle un débit élevé ? Pas forcément. Un système peut répondre vite à chaque requête mais en traiter peu à la fois, ou en traiter beaucoup à la fois pendant que chacune attend. Vous ne connaissez les deux qu'après les avoir mesurés sous la même charge, idéalement sur plusieurs paliers.

Quelle est la différence entre latence et temps de réponse ? Dans l'usage courant, ils désignent souvent la même chose. Dans JMeter, Latency est le temps jusqu'à la première partie de la réponse et Elapsed time le temps de réponse complet : vérifiez lequel un rapport affiche avant de comparer des outils.

Pourquoi le débit cesse-t-il d'augmenter pendant un test de charge ? Quelque chose a atteint sa limite : le CPU, une base de données, un pool de connexions, une limitation de requêtes (rate limit) ou le générateur de charge lui-même. À partir de là, les utilisateurs supplémentaires ne font que patienter, ce qui se voit comme une latence en hausse à débit constant.

Gatling vs Locust : simulations JVM ou locustfiles Python ?

Tue, 13 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Gatling et Locust sont deux outils open source gratuits qui gardent les tests de charge sous forme de code dans votre dépôt. Choisissez Gatling si votre équipe travaille sur la JVM ou si vous voulez des profils d'injection ouverts et fermés, des assertions et un rapport HTML dans un seul paquet. Choisissez Locust si votre équipe écrit du Python, apprécie une interface web pour lancer et suivre une exécution, et a besoin du mode distribué sans édition commerciale.

Les informations de ce comparatif Gatling vs Locust viennent de la documentation et du dépôt de chaque projet, vérifiées le 13 octobre 2026.

	Gatling	Locust
Licence	Apache 2.0 ; gRPC, MQTT et GraphQL sous une licence de composant distincte (dépôt)	MIT (dépôt)
Exécution	JVM, OpenJDK LTS 11 à 25 (version 3.16.0)	Python 3.11 ou plus récent (version 2.46.7)
Code de test	Java, Kotlin, Scala, JavaScript ou TypeScript	Python
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP et HTTPS ; les autres via un client Python
Modèle de charge	Profils d'injection ouverts ou fermés	Un pool d'utilisateurs, donc un modèle fermé
Critères de réussite	Assertions, évaluées après l'exécution	Code de sortie 1 si des requêtes échouent, ou votre propre listener
Rapports	Rapport HTML après chaque exécution	Graphiques en direct dans l'interface web, fichiers CSV, rapport HTML
Montée en charge	Gatling Enterprise	Mode master et workers intégré, opérateur Kubernetes

Quelle est la différence entre Gatling et Locust ?

Gatling exécute des simulations sur la JVM, et Locust exécute de simples programmes Python. Gatling fournit d'emblée un modèle de charge et un rapport, tandis qu'avec Locust vous écrivez vous-même la logique du test.

Le README de Gatling décrit un moteur non bloquant construit sur Netty et un SDK en cinq langages : Java, Kotlin et Scala passent par Maven, Gradle ou sbt, JavaScript et TypeScript par un SDK à part. Sa page d'installation demande un OpenJDK LTS 64 bits de 11 à 25, et Node.js 24 ou plus récent pour le SDK JavaScript.

Le README de Locust le présente comme un moyen d'écrire des tests de charge évolutifs en Python pur, et ses métadonnées de paquet exigent Python 3.11 ou plus récent. La page What is Locust précise qu'il repose sur des événements avec gevent, si bien qu'un seul processus peut gérer plusieurs milliers d'utilisateurs simultanés (vérifié le 13 octobre 2026).

Comment écrire le même test dans chaque outil ?

Dans Gatling, vous enchaînez des requêtes dans un scénario et lui donnez un profil d'injection. Dans Locust, vous écrivez une classe d'utilisateur avec des tâches et un temps d'attente entre elles.

Cinquante utilisateurs simultanés qui listent les utilisateurs puis attendent une à trois secondes, pendant cinq minutes. Avec le SDK Java de Gatling (imports omis) :

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

Le même test dans Locust :

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def list_users(self):
        self.client.get("/api/users")

La référence d'injection de Gatling range constantConcurrentUsers parmi les étapes du modèle fermé. Locust reçoit le nombre d'utilisateurs et la durée sous forme d'options (vérifié le 13 octobre 2026) :

locust -f locustfile.py --headless -u 50 -r 5 -t 5m \
  --host https://staging.example.com

Comment Gatling et Locust modélisent-ils la charge ?

Gatling propose les modèles ouvert et fermé, selon la méthode que vous appelez. Locust fait tourner un pool d'utilisateurs, ce qui correspond à un modèle fermé.

La page sur les modèles de charge de Gatling définit les systèmes fermés comme ceux qui plafonnent le nombre d'utilisateurs simultanés, et les systèmes ouverts comme ceux où les utilisateurs continuent d'arriver même quand l'application répond lentement. Elle ajoute que la plupart des sites web sont ouverts. injectOpen prend des taux d'arrivée et injectClosed des cibles de concurrence.

Le guide du locustfile indique que le temps d'attente ne peut que limiter le débit et ne lance pas de nouveaux utilisateurs pour atteindre un taux cible. Si une boucle dure plus longtemps que l'attente ne le permet, le taux passe sous la cible (vérifié le 13 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique pourquoi cela compte.

Comment lancer un test plus gros que ce qu'une machine peut générer ?

Locust intègre le mode distribué. L'édition open source de Gatling génère la charge depuis une seule machine, et les exécutions distribuées demandent Gatling Enterprise.

Locust démarre un processus avec --master et autant de processus --worker que nécessaire. Selon les docs sur la charge distribuée, un processus Python n'utilise pas plus d'un cœur, donc on lance un worker par cœur, et --processes en démarre plusieurs sur une machine. Un opérateur Kubernetes gère les exécutions distribuées dans un cluster.

La FAQ de Gatling dit que la Community Edition ne prend pas en charge les tests distribués, et le README décrit Enterprise comme exécuté sur des générateurs de charge gérés ou sur une infrastructure privée (vérifié le 13 octobre 2026).

Il existe une échappatoire pour les deux. LoadFocus, l'éditeur de ce site, n'exécute ni les simulations Gatling ni les tests Locust. Si vous préférez ne faire tourner aucun des deux à grande échelle, il exécute des scripts k6 et des plans de test JMeter depuis 25 régions cloud. Son validateur k6 avertit que les scénarios à taux d'arrivée y tournent avec un nombre fixe d'utilisateurs et ne tiennent donc pas une cadence de requêtes. Passer de l'un ou l'autre outil à ceux-là oblige à réécrire le test.

Comment décident-ils si un test a réussi, et quels rapports obtient-on ?

Gatling évalue les assertions après l'exécution et écrit un rapport HTML à chaque fois. Locust se termine avec le code 1 si une requête a échoué, et vous ajoutez d'autres contrôles sous forme de listener.

Les assertions de Gatling sont évaluées après la simulation, et une seule assertion en échec fait échouer la simulation. Son rapport HTML trace les percentiles du temps de réponse, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde.

D'après les docs headless de Locust, l'exécution se termine avec le code 1 si un échantillon a échoué, et un exemple de listener fait échouer l'exécution sur le taux d'échec, le temps de réponse moyen ou le 95e percentile. La référence de configuration cite --csv pour les fichiers de statistiques et --html pour un rapport (vérifié le 13 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

Gatling en fournit davantage, avec des limites sur les plus récents. Locust fournit HTTP et HTTPS et attend un client Python pour le reste.

Le README de Gatling liste HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events et JMS sous Apache 2.0 sans limite. gRPC, MQTT et GraphQL relèvent de la Gatling Enterprise Component License, et les tests qui les utilisent sont plafonnés à 5 utilisateurs simultanés et 5 minutes dans la Community Edition.

La page sur les autres systèmes de Locust montre comment envelopper une bibliothèque de protocole et signaler chaque appel, avec des exemples gRPC et MQTT. La bibliothèque doit fonctionner avec gevent, qui ne peut pas patcher les E/S faites en code C compilé, et locust-plugins ajoute des utilisateurs pour Kafka, Selenium et Playwright (vérifié le 13 octobre 2026).

Lequel choisir ?

Choisissez selon le langage et la façon dont vous chargez le système. Gatling convient aux équipes JVM et aux tests en modèle ouvert, Locust aux équipes Python et aux tests à logique sur mesure.

Choisissez Gatling plutôt que Locust si votre équipe vit sur la JVM et veut des tests Java, Kotlin ou Scala construits avec Maven, Gradle ou sbt, si vous avez besoin d'un modèle ouvert comme un taux d'arrivée fixe, si vous avez besoin de JMS ou de Server-Sent Events, ou si vous voulez des assertions et un rapport sans code supplémentaire.

Choisissez Locust plutôt que Gatling si votre équipe écrit du Python et veut que les tests réutilisent un client Python interne, si vous voulez une interface web pour lancer une exécution et modifier la charge en cours de route, si vous avez besoin du mode distribué dans l'outil gratuit, ou si le système reçoit surtout des utilisateurs qui attendent et que votre protocole a une bibliothèque Python compatible gevent.

Pour un constructeur de tests graphique, regardez JMeter, et pour un seul binaire sans JVM ni Python, regardez k6.

FAQ

Gatling est-il plus rapide que Locust ? Nous ne l'avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. La seule comparaison honnête consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Locust peut-il exécuter des simulations Gatling ? Pas d'après la documentation de Locust, qui ne décrit les tests que comme du code Python. Une simulation Gatling doit être réécrite en locustfile, et l'inverse vaut aussi.

LoadFocus peut-il exécuter des tests Gatling ou Locust ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour répartir une simulation Gatling sur plusieurs machines, utilisez Gatling Enterprise, et pour Locust son mode master et workers ou son opérateur Kubernetes.

JMeter vs Postman : quel outil pour tester la charge ?

Tue, 13 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Postman est un client d'API conçu pour les vérifications fonctionnelles, les collections et le travail en équipe, auquel on a ajouté un mode de test de performance. Apache JMeter est un générateur de charge depuis l'origine. Utilisez Postman pour réutiliser la collection que vous avez déjà dans un test de charge rapide ou un smoke test en CI. Utilisez JMeter quand le test de charge est le vrai sujet : nombreux protocoles, grand nombre d'utilisateurs, rapports détaillés et génération de charge distribuée.

Les informations sur Postman viennent de sa documentation et de sa page de tarifs, celles sur JMeter du site du projet, toutes vérifiées le 13 octobre 2026.

	Postman	Apache JMeter
Usage principal	Client d'API, tests fonctionnels et de collections, avec un mode performance	Tests de charge et de performance
Définition du test	Une collection de requêtes avec des scripts et des assertions `pm.test()`	Un plan de test construit dans une interface graphique et enregistré en `.jmx`
Utilisateurs virtuels	Chacun exécute la collection en boucle ; les exécutions locales sont limitées par votre machine	Un thread Java par utilisateur dans un Thread Group
Profils de charge	Fixed, Ramp up, Spike et Peak	Thread Groups avec une période de montée en charge
Origine de la charge	Votre machine ou un runner CI, ou le cloud de Postman avec un forfait payant	Votre machine, ou des serveurs JMeter distants que vous exploitez
Coût de la charge	Exécutions locales dans tous les forfaits ; exécutions cloud à 0,04 $ par heure d'utilisateur virtuel	Gratuit, licence Apache 2.0
Réussite ou échec en CI	`postman performance run` avec `--pass-if`	Mode CLI (`jmeter -n`)

Que fait le test de performance de Postman ?

Il exécute les requêtes d'une collection avec plusieurs utilisateurs virtuels en parallèle, pendant un nombre de minutes défini. Chaque utilisateur répète les requêtes dans l'ordre, et vos scripts et assertions existants s'exécutent sous charge.

Selon la documentation sur les tests de performance, la collection de vos tests fonctionnels est aussi votre test de charge, sans script ni langage distinct à maintenir (vérifié le 13 octobre 2026). Vous choisissez une durée et un nombre d'utilisateurs virtuels, puis un profil Fixed, Ramp up, Spike ou Peak, comme le décrit la page de configuration.

Quelles sont les limites de Postman pour les tests de charge ?

La limite principale est l'origine de la charge. Une exécution locale est plafonnée par la machine qui la lance, et tout ce qui dépasse suppose un forfait payant.

Pour les exécutions locales, la documentation de Postman indique que le nombre d'utilisateurs virtuels dépend des ressources système disponibles et de la collection utilisée, que les scripts de pré-requête et de post-réponse réduisent le nombre d'utilisateurs simulables, et que l'exécution s'arrête si la machine dépasse son seuil de ressources. Elle suggère un premier test de 10 à 20 utilisateurs virtuels (vérifié le 13 octobre 2026). Au-delà, le générateur de charge peut lui-même fausser vos mesures, ce qui explique que Postman affiche aussi les pics de CPU et de mémoire de la machine de test.

Les données sont la limite suivante. D'après la même page de configuration, les fichiers de données CSV et JSON ne fonctionnent que pour les exécutions locales, tandis que les datasets fonctionnent en local et dans le cloud.

Combien coûte le test de charge avec Postman ?

Les exécutions de performance locales sont incluses dans tous les forfaits. Les exécutions cloud sont réservées aux forfaits payants et facturées à l'usage, en heures d'utilisateur virtuel.

La page de tarifs de Postman indique des tests de performance locaux illimités et des tests de performance cloud à 0,04 $ par heure d'utilisateur virtuel (vérifié le 13 octobre 2026). À ce tarif affiché, 500 utilisateurs virtuels pendant une heure représentent 500 heures d'utilisateur virtuel, soit 20 $, en plus du prix du forfait. Les adresses IP statiques pour atteindre des cibles derrière un pare-feu relèvent de l'offre Enterprise. Nous n'avons pas chiffré les forfaits eux-mêmes : consultez la page pour les tarifs actuels par utilisateur.

Quels protocoles peut-on tester sous charge ?

JMeter a une longue liste documentée. Pour Postman, nous n'avons trouvé aucune liste des protocoles pris en charge dans les exécutions de performance, donc nous n'affirmons rien à ce sujet.

La page d'accueil de JMeter cite HTTP et HTTPS, SOAP et REST, FTP, les bases de données via JDBC, LDAP, la messagerie JMS, le courrier SMTP, POP3 et IMAP, les commandes natives et scripts shell, TCP et les objets Java (vérifié le 13 octobre 2026). Postman gère d'autres types de requêtes dans l'application, comme GraphQL, gRPC et WebSocket, mais cela ne dit pas lesquels fonctionnent sous charge. Essayez-en un avant de vous y fier.

Comment monter en charge au-delà d'une machine ?

Postman monte en charge par son propre cloud, JMeter par des serveurs que vous exploitez vous-même. Le premier démarre plus facilement, le second vous donne le contrôle.

Avec un forfait payant, les exécutions cloud de Postman répartissent la charge sur des workers gérés, si bien qu'une seule machine ne limite plus le test. Le mode de test distant de JMeter permet à un client de piloter de nombreux serveurs JMeter. Chaque nœud doit avoir la même version de JMeter, un keystore pour RMI sur SSL sauf si vous le désactivez, et sa propre copie des fichiers de données (vérifié le 13 octobre 2026).

Il existe une troisième voie pour les plans de test JMeter. LoadFocus, l'éditeur de ce site, exécute vos plans de test JMeter existants depuis 25 régions cloud. Vous importez le fichier .jmx et réglez utilisateurs virtuels, durée et montée en charge, sans serveur distant à configurer. LoadFocus n'exécute que JMeter et k6, donc pas une collection Postman.

Quel outil choisir ?

Choisissez Postman plutôt que JMeter pour les vérifications fonctionnelles et de contrat, pour une équipe qui partage des collections dans un espace de travail, et pour un smoke test rapide d'une API que vous testez déjà. Choisissez JMeter quand le test de charge est l'objectif principal, ou quand il vous faut plusieurs protocoles, beaucoup d'utilisateurs, ou des tests qui restent dans votre propre dépôt.

Postman convient à un contrôle court en CI : postman performance run se termine avec un code de sortie non nul quand un seuil comme le 95e percentile n'est pas respecté, ce qui fait échouer le build. JMeter est préférable pour la charge sur des bases de données ou de la messagerie, pour les longs tests d'endurance, et pour le tableau de bord HTML avec tables APDEX et percentiles que sa documentation décrit.

Beaucoup d'équipes utilisent les deux : Postman pour construire et vérifier les contrôles d'API, JMeter pour donner un vrai volume aux parcours critiques.

FAQ

Postman peut-il remplacer JMeter pour les tests de charge ? Pour de petites vérifications d'API HTTP, oui, puisque la collection que vous avez déjà est le test. Pour une forte concurrence, d'autres protocoles ou de longues exécutions, les limites documentées des exécutions locales et la tarification à l'usage du cloud font de JMeter la base la plus sûre.

Postman peut-il exécuter un fichier .jmx de JMeter ? Nous n'avons rien trouvé dans sa documentation qui importe un plan de test JMeter. Les tests de performance de Postman reposent sur des collections : un fichier .jmx devrait être reconstruit.

JMeter est-il gratuit ? Oui. La version actuelle sur la page de téléchargement est la 5.6.3, qui demande Java 8 ou plus récent (vérifié le 13 octobre 2026). Vous payez les machines qui génèrent la charge, ou un service cloud qui exécute vos plans.

k6 vs Locust : scripts JavaScript ou utilisateurs Python ?

Tue, 13 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

k6 et Locust sont deux outils open source qui gardent un test de charge sous forme de code dans votre dépôt, et l'un comme l'autre testera correctement une API HTTP sous charge. Choisissez Locust si votre équipe écrit du Python et veut de la logique de test en Python pur. Choisissez k6 si vous écrivez du JavaScript, voulez des seuils de réussite intégrés, ou avez besoin d'un test qui tient un taux d'arrivée.

Les informations de ce comparatif k6 vs Locust viennent de la documentation et du dépôt de chaque projet, vérifiées le 13 octobre 2026.

	k6	Locust
Licence	AGPL-3.0 (dépôt)	MIT (dépôt)
Exécution	Un binaire Go avec un moteur JavaScript intégré (version v2.3.0)	Python 3.11 ou plus récent (version 2.46.7)
Scripts de test	JavaScript, ou TypeScript dont les types sont retirés	Classes Python dans un locustfile
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSockets, gRPC	HTTP et HTTPS
Modèle de charge	Six exécuteurs, dont deux arrival-rate (modèle ouvert)	Un groupe d'utilisateurs qui attendent chacun un délai (modèle fermé)
Réussite ou échec	Seuils, qui peuvent interrompre une exécution plus tôt	Code de sortie 1 si des requêtes échouent ; autres limites via un listener
Tests navigateur	Module navigateur intégré	Utilisateurs navigateur via le projet séparé locust-plugins
Montée en charge	k6-operator sur Kubernetes, ou Grafana Cloud k6	Master et workers, un opérateur Kubernetes, ou Azure Load Testing

Quelle est la différence entre k6 et Locust ?

La différence principale est le langage dans lequel vous écrivez les tests. k6 exécute du JavaScript dans un programme Go compilé, tandis que Locust exécute votre code Python et s'appuie sur gevent pour gérer de nombreux utilisateurs simultanés.

k6 s'installe comme paquet ou binaire autonome, sans autre environnement d'exécution. Il exécute aussi des fichiers .ts, mais son support de TypeScript retire les types sans les vérifier. Locust s'installe avec pip install locust, et sa page What is Locust indique que les tests sont du Python ordinaire, versionné comme n'importe quel autre code (vérifié le 13 octobre 2026).

Comment écrire le même test dans chaque outil ?

Les deux expriment le test sous forme de petit programme. Voici un test avec 50 utilisateurs pendant cinq minutes, qui échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent.

Dans k6, les objectifs font partie du script, sous forme de seuils :

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

Dans Locust, l'utilisateur est une classe, et les mêmes objectifs vont dans un listener, d'après le modèle de la documentation du mode headless :

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

On les lance avec k6 run script.js et locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (vérifié le 13 octobre 2026).

Comment k6 et Locust modélisent-ils la charge ?

k6 prend en charge les deux modèles de charge, alors que Locust décrit la charge comme un nombre fixe d'utilisateurs. Dans k6 vous choisissez le modèle par l'exécuteur, dans Locust par le nombre d'utilisateurs et le délai d'attente.

k6 propose six exécuteurs. Quatre sont fermés : un utilisateur virtuel ne démarre son itération suivante que lorsque la précédente est terminée. Les deux exécuteurs arrival-rate suivent le modèle ouvert, où les itérations démarrent indépendamment de la durée des précédentes. Le guide du locustfile précise que le délai d'attente peut seulement limiter le débit et ne peut pas lancer de nouveaux utilisateurs pour atteindre une cadence cible (vérifié le 13 octobre 2026).

Si votre objectif est « 300 requêtes arrivent chaque seconde, quel que soit le temps de réponse », k6 sait l'exprimer directement. Notre guide sur le modèle de charge ouvert et fermé explique quand utiliser chacun.

Comment k6 et Locust décident-ils si un test est réussi ?

k6 fait des critères de réussite une fonction centrale, et Locust laisse l'essentiel à votre code. Un seuil k6 non respecté termine l'exécution avec un code de sortie non nul, et abortOnFail arrête le test dès qu'il échoue.

Locust se termine avec le code 1 si une requête a échoué. Pour des limites sur le taux d'échec, la moyenne ou le 95e percentile, sa documentation montre un listener comme celui ci-dessus, qui fixe lui-même le code de sortie (vérifié le 13 octobre 2026). Notre guide sur les critères de réussite d'un test de charge aide à choisir les limites.

Quels protocoles chaque outil couvre-t-il ?

k6 livre quatre protocoles et un module navigateur, Locust livre HTTP et HTTPS et vous laisse envelopper n'importe quel client Python pour le reste.

k6 liste HTTP/1.1, HTTP/2, WebSockets et gRPC comme protocoles intégrés, avec d'autres via des extensions xk6, ainsi qu'un module navigateur qui pilote un navigateur basé sur Chromium. La page de Locust sur les autres systèmes dit qu'il n'a de support intégré que pour HTTP/HTTPS mais qu'on peut l'étendre pour tester presque n'importe quel système, en enveloppant une bibliothèque de protocole et en signalant chaque appel comme une requête. La bibliothèque doit coopérer avec gevent (vérifié le 13 octobre 2026).

Comment lancer un test plus gros que ce qu'une machine peut générer ?

Locust monte en charge avec un master et des workers, k6 avec un opérateur Kubernetes ou un service hébergé. Les deux peuvent répartir un test sur de nombreuses machines.

La documentation du mode distribué de Locust indique qu'un processus peut faire plus de mille requêtes par seconde pour un plan de test simple ; les tests plus gros utilisent donc un worker par cœur de processeur, sur autant de machines que nécessaire. Le k6-operator répartit un test sur plusieurs instances k6 dans un cluster Kubernetes, et Grafana Cloud k6 est la voie hébergée (vérifié le 13 octobre 2026).

Il existe une troisième voie pour les scripts k6. LoadFocus, qui publie ce site, exécute des scripts k6 depuis 25 régions cloud, avec les utilisateurs et la durée tirés des réglages du test. Son validateur de scripts avertit que les scénarios arrival-rate y tournent avec un nombre fixe d'utilisateurs : un script en modèle ouvert ne tient donc pas son taux d'arrivée sur LoadFocus. LoadFocus n'exécute pas Locust : il exécute uniquement des scripts k6 et des plans de test JMeter.

Quels rapports obtient-on ?

k6 affiche un récapitulatif en fin de test et peut exporter un rapport HTML depuis son tableau de bord web. Locust montre des graphiques en direct dans son interface web et écrit des fichiers à la demande.

Le récapitulatif de fin de test de k6 s'affiche dans le terminal, et son tableau de bord web exporte un rapport HTML autonome quand vous définissez K6_WEB_DASHBOARD_EXPORT. Locust sert une interface web sur le port 8089 avec des graphiques en direct, et sa référence de configuration liste les sorties --csv, --html et --json (vérifié le 13 octobre 2026).

Lequel choisir ?

Locust convient aux équipes Python, et k6 à celles qui veulent des seuils intégrés et un modèle de charge ouvert. Les protocoles et la montée en charge tranchent la plupart des autres cas.

Choisissez Locust plutôt que k6 si votre équipe écrit du Python et veut des boucles, des branchements, des données générées et son propre client d'API en Python pur, si vous voulez réutiliser des bibliothèques Python pour un protocole, ou si vous voulez une interface web avec des graphiques en direct pour explorer un système. Choisissez k6 plutôt que Locust si votre équipe écrit du JavaScript ou du TypeScript, si des seuils doivent faire échouer un build CI et arrêter tôt une mauvaise exécution, si vous avez besoin d'un taux d'arrivée constant, ou si vous voulez gRPC et les tests navigateur dans le même outil.

Pour une vue plus large, lisez notre revue du test de charge avec Locust.

FAQ

Locust est-il plus rapide que k6 ? Nous ne l'avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. Le test équitable est le même scénario avec les deux outils sur votre propre matériel.

Locust peut-il exécuter des scripts k6 ? Pas d'après la documentation de Locust, qui décrit des tests écrits en Python dans un locustfile. Un script k6 est du JavaScript, il faut donc le réécrire en classe d'utilisateur Python, et les seuils deviennent un listener.

LoadFocus peut-il exécuter des tests Locust ? Non. LoadFocus exécute des scripts k6 et des plans de test JMeter. Pour faire monter en charge un test Locust, utilisez son mode master et workers, l'opérateur Kubernetes ou Azure Load Testing.

Coordinated omission : ce que c'est et comment l'éviter

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

La coordinated omission est une erreur de mesure : un générateur de charge attend chaque réponse lente avant d'envoyer sa requête suivante, il envoie donc moins de requêtes au moment même où le système ralentit et enregistre trop peu des mauvais moments. Les percentiles que vous lisez ensuite paraissent alors meilleurs que ce que les utilisateurs ont vécu. Pour l'éviter, envoyez les requêtes selon un calendrier qui ignore les temps de réponse et mesurez chaque requête à partir du moment où elle aurait dû partir.

Les informations sur les outils viennent de la documentation ou du dépôt de chaque projet, vérifiées le 9 octobre 2026.

Outil	Ce qu'il propose	Ce qu'il faut vérifier
wrk2	Un taux constant (`-R`), latence mesurée depuis l'envoi prévu	`--u_latency` ajoute la vue non corrigée
HdrHistogram	Deux méthodes qui comblent les mesures manquantes	En appliquer une seule, jamais les deux
k6	Les executors à taux d'arrivée	Le compteur `dropped_iterations`
Gatling	Des étapes `injectOpen` comme `constantUsersPerSec`	Les étapes sont dans `injectOpen`
Locust	`constant_throughput` cadence chaque utilisateur	Le taux atteint par rapport à la cible
JMeter	Open Model Thread Group (5.5 et plus, expérimental)	Un Thread Group classique est un pool fermé

Qu'est-ce que la coordinated omission ?

C'est l'erreur qui survient quand le côté qui mesure cesse de prendre des mesures parce que le système est lent, si bien que les mesures qui manquent sont précisément les lentes. Perdre des mesures au hasard bouge à peine un percentile ; les perdre au rythme d'un ralentissement les fausse tous.

Le nom vient de Gil Tene, dont un message de 2013 sur une liste de diffusion trace exactement cette frontière. Il est l'auteur d'origine d'HdrHistogram, wrk2 se trouve sur son compte GitHub, et la documentation des deux projets explique l'effet (vérifié le 9 octobre 2026). La documentation de k6 emploie le terme pour un modèle de charge fermé qui freine sa propre charge, une cause fréquente. Notre article sur le modèle de charge ouvert ou fermé traite ce choix ; celui-ci s'en tient à la mesure.

Comment un test de charge finit-il par masquer les réponses lentes ?

Un générateur en boucle fermée n'envoie la requête suivante sur une connexion qu'après l'arrivée de la réponse précédente. Si une réponse prend une seconde, cette connexion n'envoie rien pendant une seconde, et les requêtes qu'elle aurait envoyées n'obtiennent jamais de temps de réponse.

Le README de wrk2 le dit du modèle de wrk, qui mesure chaque requête du premier octet envoyé à la réponse complète : comme une connexion n'envoie qu'après une réponse, le générateur se coordonne avec le serveur et évite de mesurer pendant les périodes de forte latence (vérifié le 9 octobre 2026).

Le README d'HdrHistogram propose une expérience de pensée. Un système mesuré toutes les 10 ms répond en 1 ms pendant 100 secondes, puis se fige pendant 100 secondes, ce qui donne une seule mesure de 100 secondes. L'histogramme brut place environ 99,99 % des résultats à 1 ms ou moins ; corrigé des mesures bloquées, il n'en place qu'environ la moitié.

Comment savoir si vos résultats souffrent de coordinated omission ?

Comparez le taux envoyé au taux prévu. Si le taux de requêtes a baissé pendant que les temps de réponse montaient, le générateur a levé le pied et la période lente est sous-représentée.

La charge était définie en utilisateurs ou en connexions, sans taux. N'importe quelle boucle fermée peut produire l'erreur.
Le taux de requêtes baisse là où les temps de réponse montent. Un creux du taux pendant un pic signifie que des requêtes ne sont jamais parties.
Le maximum écrase le 99e percentile. Quelques mesures énormes parmi des milliers de rapides, c'est l'exemple ci-dessus en miniature. Lisez toute la distribution des temps de réponse, en gardant à l'esprit qu'elle ne compte que les requêtes envoyées.
Le générateur de charge manquait de CPU. LoadFocus documente qu'un moteur proche de 100 % de CPU ne peut pas envoyer au taux configuré, et ses résultats affichent un avertissement de saturation du générateur de charge quand un moteur a atteint ou dépassé 80 % de CPU en pointe.

Comment wrk2 évite-t-il la coordinated omission ?

Il envoie à taux constant et mesure chaque requête à partir du moment où le plan prévoyait son départ. Une requête partie en retard parce que sa connexion était occupée se voit compter l'attente.

wrk2 ajoute à wrk un argument de taux (-R, requêtes par seconde au total) et enregistre les latences dans un HdrHistogram. --u_latency ajoute au rapport l'histogramme non corrigé, marqué CO, comme dans l'exemple du README :

wrk -t2 -c100 -d30s -R2000 --u_latency http://127.0.0.1:80/index.html

Dans le second exemple du README, une pause du serveur de 1,4 seconde pendant un test de 30 secondes rend le 99e percentile corrigé 200 fois plus élevé que le non corrigé. Le README qualifie aussi le projet d'expérimental et prévient que des tests de moins de 10 à 20 secondes risquent de ne rien apprendre (vérifié le 9 octobre 2026). Notre revue des outils de benchmark HTTP compare wrk2 à hey, oha et d'autres.

Comment HdrHistogram corrige-t-il les latences enregistrées ?

Si vous connaissez l'intervalle auquel les requêtes devaient partir, il ajoute les mesures qu'une longue réponse a bloquées. La correction se fait à l'enregistrement ou après coup, sur une copie.

recordValueWithExpectedInterval enregistre une valeur et, si elle dépasse l'intervalle, ajoute des valeurs qui décroissent par pas de cet intervalle. copyCorrectedForCoordinatedOmission renvoie une copie corrigée d'un histogramme terminé. La JavaDoc présente les deux méthodes comme mutuellement exclusives (vérifié le 9 octobre 2026).

// intervalle prévu : 10 ms, valeurs en microsecondes
Histogram h = new Histogram(3);
h.recordValueWithExpectedInterval(latencyUs, 10_000);

// ou, après le test, sur un histogramme brut :
Histogram fixed = raw.copyCorrectedForCoordinatedOmission(10_000);

La correction ne vaut que ce que vaut l'intervalle que vous lui passez. Elle convient donc à un générateur censé envoyer à un rythme régulier.

Comment k6, Gatling, Locust et JMeter s'y prennent-ils ?

k6, Gatling et JMeter peuvent lancer le travail selon un calendrier qui n'attend pas les réponses. Locust cadence chaque utilisateur mais ne peut pas lancer d'utilisateurs supplémentaires pour tenir un taux.

k6. Dans les executors à taux d'arrivée, les itérations démarrent indépendamment de la réponse du système tant qu'un utilisateur virtuel est libre. Quand aucun ne l'est, k6 saute l'itération et la compte dans dropped_iterations, ce qui, tard dans un test, peut signifier que le système se dégrade (vérifié le 9 octobre 2026). Une itération abandonnée n'a pas de temps de réponse : lisez ce compteur à côté des percentiles. Sur LoadFocus, les scénarios à taux d'arrivée des scripts k6 tournent avec un nombre fixe d'utilisateurs, soit un modèle fermé. Lancez k6 vous-même quand le taux d'arrivée est l'objet du test.

Gatling. Des étapes comme constantUsersPerSec dans injectOpen lancent de nouveaux utilisateurs virtuels à un taux fixé, que les précédents aient terminé ou non (vérifié le 9 octobre 2026).

Locust. constant_throughput ajuste l'attente de chaque utilisateur pour qu'il exécute une tâche au plus un certain nombre de fois par seconde. La documentation précise que le temps d'attente ne peut que limiter le taux et ne lance pas de nouveaux utilisateurs, et la référence de l'API ajoute qu'une tâche qui dépasse son intervalle n'est suivie d'aucune attente. Une réponse lente retarde donc quand même cet utilisateur (vérifié le 9 octobre 2026).

JMeter. Un Thread Group est un pool de threads qui bouclent, donc une boucle fermée. JMeter 5.5 a ajouté l'Open Model Thread Group, expérimental, qui suit un calendrier comme rate(1/sec) random_arrivals(2 min) et, selon les notes de version, crée des threads au besoin (vérifié le 9 octobre 2026).

Un modèle de charge ouvert supprime-t-il la coordinated omission ?

Il supprime la cause principale, un générateur qui attend avant d'envoyer. Deux failles restent : un générateur à court d'utilisateurs ou de CPU prend quand même du retard sur son calendrier, et chaque utilisateur d'un parcours en plusieurs étapes attend toujours ses propres réponses.

La première se voit sous forme d'itérations abandonnées ou d'un moteur saturé ; dans les deux cas, relancez le test avec plus de marge. La seconde est inhérente à la plupart des tests HTTP : le README de wrk2 note qu'envoyer sans attendre ne convient qu'aux protocoles non bloquants ou à une requête par connexion, et c'est pourquoi wrk2 corrige plutôt la mesure du temps.

FAQ

Qui a nommé la coordinated omission ? Gil Tene, l'auteur d'origine d'HdrHistogram, dont le fork wrk2 de wrk est conçu pour l'éviter. Son message de 2013 sur la liste de diffusion mechanical-sympathy la décrit comme un problème qu'il appelle ainsi.

La coordinated omission est-elle la même chose qu'un modèle de charge fermé ? Les deux sont liés. Un modèle fermé en est une cause fréquente, puisque chaque utilisateur virtuel attend sa réponse avant de renvoyer, et le README de wrk2 retrouve aussi l'effet dans le code de supervision.

Faut-il corriger tous les histogrammes de latence ? Seulement si vous connaissez l'intervalle auquel les requêtes étaient prévues, car HdrHistogram en a besoin pour combler les mesures manquantes. Appliquez à un jeu de données une seule de ses deux méthodes de correction, jamais les deux.

Test de charge Gatling : l'outil JVM passé en revue

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Gatling est un outil de test de charge gratuit sous licence Apache 2.0, dans lequel chaque test est une simulation écrite en code, exécutée sur la JVM et suivie d'un rapport HTML. Un test de charge Gatling convient aux équipes de développement qui veulent leurs tests dans le dépôt, des modèles de charge ouverts ou fermés et des assertions qui font échouer le build. Les équipes qui veulent un éditeur de tests graphique ou beaucoup de protocoles seront mieux servies par JMeter, et celles qui veulent un seul binaire sans JVM par k6.

Nous n'avons pas exécuté Gatling pour cette revue. Les faits viennent de la documentation, du dépôt et des pages de version de Gatling, vérifiés le 9 octobre 2026, et les jugements sont les nôtres.

Sujet	Gatling
Licence	Apache 2.0, sauf les plugins gRPC, MQTT et GraphQL
Environnement	JVM, OpenJDK LTS 64 bits de 11 à 25
Version actuelle	3.16.0 (29 septembre 2026)
Langages des tests	Java, Kotlin, Scala, JavaScript, TypeScript
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, SSE, JMS
Résultats	Rapport HTML statique par exécution
Build et CI	Plugins Maven, Gradle, sbt et npm
Montée en échelle	Gatling Enterprise (commercial)

Qui développe Gatling, et le projet est-il toujours maintenu ?

Gatling Corp, une entreprise française, développe Gatling et en détient les droits d'auteur. Le projet est activement maintenu, avec trois versions JVM publiées depuis le début de 2026.

La page des licences attribue les droits d'auteur à Gatling Corp. Maven Central liste la 3.15.0 en février, la 3.15.1 en mai et la 3.16.0 le 29 septembre 2026, et le SDK JavaScript est passé en 3.16.1 le 6 octobre. Les notes de version 3.16 ajoutent GraphQL et des files partagées entre utilisateurs virtuels. Le README présente le dépôt comme la Community Edition, libre d'utilisation, y compris commerciale (vérifié le 9 octobre 2026).

De quoi avez-vous besoin pour exécuter Gatling ?

D'une JVM 64 bits pour Java, Kotlin ou Scala, ou de Node.js pour JavaScript et TypeScript. Dans les deux cas, la simulation elle-même tourne sur une JVM.

La page d'installation prend en charge les versions LTS d'OpenJDK de 11 à 25 et exclut les JVM 32 bits et OpenJ9. La CLI JavaScript demande Node.js 24 ou plus récent et télécharge un bundle d'exécution Gatling, ainsi que GraalVM selon le README de gatling-js (vérifié le 9 octobre 2026).

Comment une simulation Gatling est-elle structurée ?

Une simulation définit des scénarios, donne à chacun un profil d'injection et y attache une configuration de protocole, le tout enregistré par un seul appel à setUp.

Dans la référence des simulations, un scénario enchaîne des requêtes avec des pauses, des boucles et des conditions. Cette simulation Java enregistre l'identifiant d'un produit trouvé par une recherche, marque une pause d'une à trois secondes et ouvre la fiche produit, tandis que les arrivées montent à 20 utilisateurs par seconde puis s'y maintiennent dix minutes :

public class ShopSimulation extends Simulation {

  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Les imports sont omis, et #{id} lit la valeur enregistrée grâce à l'Expression Language de Gatling. Gatling vs k6 montre une simulation en JavaScript.

Faut-il injecter les utilisateurs en modèle ouvert ou fermé ?

En modèle ouvert pour la plupart des sites web et des API, où de nouveaux utilisateurs continuent d'arriver même quand le système ralentit. Le modèle fermé convient aux systèmes qui plafonnent la concurrence, comme une file d'attente de billetterie.

La référence de l'injection sépare l'API : injectOpen prend des taux d'arrivée comme rampUsersPerSec, et injectClosed des cibles de concurrence comme constantConcurrentUsers. La page sur les modèles de charge indique que la plupart des sites web se comportent comme des systèmes ouverts et qu'un profil ne peut pas mélanger les deux (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique comment choisir.

Comment fonctionnent les checks, les assertions et le rapport ?

Les checks vérifient chaque réponse et peuvent en extraire des valeurs, tandis que les assertions jugent l'exécution entière une fois terminée. Chaque exécution produit ensuite un rapport HTML.

Sans check de statut explicite, Gatling vérifie que chaque réponse HTTP est en 2XX ou 304. Les assertions portent sur les temps de réponse, le nombre de requêtes ou les requêtes par seconde, globalement ou par requête, et une seule assertion en échec fait échouer la simulation. Le rapport HTML présente les tranches de temps de réponse et les percentiles, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde ; ses percentiles dans le temps ne comptent que les requêtes réussies (vérifié le 9 octobre 2026).

Comment Gatling s'intègre-t-il au build et à la CI ?

Par son plugin Maven, Gradle, sbt ou npm, qui tourne dans n'importe quel système de CI. Une assertion en échec fait échouer le build.

Le plugin Maven rattache gatling:test à la phase integration-test, si bien que mvn verify le lance, et avec CI=true il ne demande plus quelle simulation exécuter (l'exécution échoue alors si le projet contient plus d'une simulation et qu'aucune n'est désignée). Le plugin Gradle utilise gatlingRun, et le plugin sbt n'accepte que des simulations en Scala. Les intégrations CI toutes prêtes de Gatling, comme son action GitHub, lancent des exécutions Gatling Enterprise (vérifié le 9 octobre 2026). Notre guide GitHub Actions traite le côté workflow.

Quels protocoles Gatling prend-il en charge ?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events et JMS sont fournis sans limite. gRPC, MQTT et GraphQL sont des plugins séparés, plafonnés à 5 utilisateurs et 5 minutes hors de Gatling Enterprise.

Le README place les cinq premiers sous Apache 2.0. Les pages d'installation de gRPC, MQTT et GraphQL placent chaque plugin sous la Gatling Enterprise Component License : sans limite sur Gatling Enterprise, tandis qu'un test avec la Community Edition s'arrête à 5 utilisateurs ou 5 minutes. Cette licence accorde un usage gratuit pendant un an au plus, uniquement pour tester en interne vos propres applications web ; elle prend fin dès qu'une limite est atteinte, et Gatling peut modifier ces limites. GraphQL exige la 3.16.0 ou plus récente. Ses notes de version et le README indiquent que le SDK JavaScript ne le prend pas encore en charge, même si la page d'installation cite déjà un paquet npm : vérifiez ce point avant de prévoir un test GraphQL en JavaScript (vérifié le 9 octobre 2026). Notre guide pour tester la charge d'une API GraphQL contourne ce plafond avec de simples requêtes HTTP.

Qu'apporte Gatling Enterprise ?

Gatling Enterprise est l'édition commerciale, sur le même moteur. Elle génère la charge depuis une infrastructure gérée ou privée, ce que l'édition gratuite ne fait pas.

D'après le README, Enterprise exécute les tests sur des générateurs de charge gérés ou dans vos propres comptes AWS, Azure, GCP ou Kubernetes, et ajoute des tableaux de bord en direct, des tendances, des équipes avec SSO et des intégrations CI/CD. La FAQ précise que la Community Edition ne prend pas en charge les tests distribués et que les simulations passent sur Enterprise sans modification (vérifié le 9 octobre 2026).

LoadFocus, l'éditeur de ce site, n'exécute pas de simulations Gatling. Il exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud ; pour Gatling, la voie vers davantage de machines reste donc Gatling Enterprise.

Quels sont les points forts de Gatling, et ses limites ?

Gatling brille par ses tests sous forme de code relisible, ses modèles de charge et ses rapports sans configuration. Il est plus faible sur les protocoles au-delà du web et de la messagerie, et pour monter gratuitement au-delà d'une machine.

Le README met en avant son moteur : non bloquant, construit sur Netty, où chaque utilisateur virtuel est un message léger. Les limites que la documentation énonce elle-même (vérifié le 9 octobre 2026) :

Gatling n'est pas un navigateur : selon la page du protocole HTTP, il n'exécute pas de JavaScript.
Le SDK JavaScript n'a pas de JMS et ne peut pas utiliser de bibliothèques npm qui exigent des binaires natifs ou des API propres à Node.js.
Le cache HTTP est activé par défaut, ce qui peut réduire le nombre de requêtes.
Le format de simulation.log n'est pas documenté et peut changer à tout moment.

Quand choisir plutôt k6, JMeter ou Locust ?

Choisissez un autre outil quand son langage, ses protocoles ou sa voie gratuite vers la montée en échelle conviennent mieux à votre équipe.

Notre panorama des outils de test de charge open source place Gatling à côté de cinq autres.

Choisissez plutôt k6 si vous voulez en CI un seul binaire sans JVM, des thresholds capables d'arrêter tôt une exécution en échec, ou gRPC parmi ses protocoles intégrés (vérifié le 9 octobre 2026). Gatling vs k6 compare les deux.

Choisissez plutôt JMeter si vos testeurs construisent leurs tests dans une interface graphique, ou si vous avez besoin de JDBC, LDAP ou FTP dans son cœur (vérifié le 9 octobre 2026). LoadFocus exécute vos plans de test JMeter existants depuis 25 régions cloud, et Gatling vs JMeter va plus loin.

Choisissez plutôt Locust si votre équipe écrit en Python et veut un mode distribué dans l'outil gratuit (vérifié le 9 octobre 2026). Notre revue de Locust le présente.

FAQ

Gatling est-il gratuit pour un usage commercial ? Oui. La Community Edition est sous Apache 2.0. Les plugins gRPC, MQTT et GraphQL ont leur propre licence et s'arrêtent à 5 utilisateurs et 5 minutes hors de Gatling Enterprise.

Faut-il Java pour utiliser Gatling ? Pour Java, Kotlin ou Scala, oui : un OpenJDK LTS 64 bits de 11 à 25. Le SDK JavaScript demande Node.js 24 ou plus récent, et sa CLI télécharge elle-même l'environnement JVM.

LoadFocus peut-il exécuter des tests Gatling ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour répartir une simulation Gatling sur plusieurs machines, utilisez Gatling Enterprise.

Gatling vs JMeter : du code ou un plan de test graphique ?

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Gatling et Apache JMeter sont deux outils de test de charge gratuits et open source qui tournent sur la JVM, et le choix dépend surtout de la façon dont votre équipe veut construire ses tests. Choisissez Gatling si vous voulez des tests sous forme de code en Java, Kotlin, Scala, JavaScript ou TypeScript, des profils d'injection ouverts et un rapport HTML après chaque exécution. Choisissez JMeter si vous avez besoin de protocoles comme JDBC, LDAP, FTP ou le mail sans rien ajouter, si vous préférez construire vos tests dans une interface graphique, ou si vous avez déjà des plans de test .jmx.

Les informations de ce comparatif Gatling vs JMeter viennent de la documentation et du dépôt de chaque projet, vérifiées le 9 octobre 2026.

	Gatling	Apache JMeter
Licence	Apache 2.0 ; gRPC, MQTT et GraphQL sous une licence de composant distincte (dépôt)	Apache 2.0 (dépôt)
Environnement d'exécution	JVM, OpenJDK LTS 11 à 25 (version 3.16.0)	JVM, Java 8 ou plus récent (version 5.6.3)
Tests écrits en	Code Java, Kotlin, Scala, JavaScript ou TypeScript	Plans de test construits dans une interface graphique, enregistrés en XML (`.jmx`)
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, mail, TCP, commandes shell, objets Java
Enregistreur	Proxy HTTP ou convertisseur de fichiers HAR	HTTP(S) Test Script Recorder (proxy)
Modèle de charge	Profils d'injection ouverts ou fermés	Thread Groups ; un Open Model Thread Group expérimental
Mise à l'échelle	Une seule machine ; l'exécution distribuée demande Gatling Enterprise	Mode distant intégré, un client qui pilote plusieurs serveurs
CI et exécution sans interface	Plugins Maven, Gradle, sbt et npm ; une assertion en échec fait échouer l'exécution	Mode CLI (`jmeter -n`) ; plugins tiers pour Maven, Gradle et Jenkins
Rapports	Rapport HTML après chaque exécution	Tableau de bord HTML ; résultats en direct via un Backend Listener

Quelle est la différence entre Gatling et JMeter ?

Dans Gatling, un test est un programme dans un projet de build. Dans JMeter, un test est un arbre d'éléments que vous assemblez dans une interface graphique de bureau puis enregistrez dans un fichier XML, et la plupart des autres différences en découlent.

Le README de Gatling appelle les tests des simulations et les range dans votre dépôt comme du code applicatif, exécutés via un plugin Maven, Gradle, sbt ou npm. Le SDK JavaScript et TypeScript s'installe avec npm et télécharge son propre environnement GraalVM.

Un plan JMeter contient un Thread Group pour les utilisateurs, des samplers pour les requêtes, des assertions et des listeners pour les résultats. JMeter 5.6.3, la version actuelle sur la page de téléchargement, demande Java 8 ou plus récent. Le README de la branche de développement de JMeter exige déjà Java 17 (vérifié le 10 octobre 2026). Sous le capot, JMeter exécute chaque utilisateur virtuel dans un thread Java, tandis que le README de Gatling décrit les utilisateurs virtuels comme des messages légers sur un moteur non bloquant construit sur Netty.

Comment écrit-on un test avec chaque outil ?

Dans Gatling, vous écrivez une classe de simulation qui définit un scénario, un profil d'injection et des assertions. Dans JMeter, vous ajoutez un Thread Group et des samplers dans l'interface graphique, vous enregistrez le plan puis vous le lancez en ligne de commande.

Une simulation Java inspirée du tutoriel de première simulation de Gatling : les nouveaux utilisateurs arrivent d'abord à un par seconde, passent à dix par seconde en une minute, puis restent à ce rythme pendant cinq minutes. L'exécution échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent :

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1);

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Lancez-la avec ./mvnw gatling:test ; une simulation JavaScript ou TypeScript se lance avec npx gatling run.

Dans JMeter, le même test est un Thread Group qui contient un sampler HTTP Request, et une Duration Assertion peut marquer en échec chaque réponse trop lente. Le guide de démarrage construit le plan en mode GUI et l'exécute en mode CLI, et -e -o ajoute le rapport HTML :

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Les deux outils peuvent enregistrer un premier jet depuis un navigateur. Le Recorder de Gatling fonctionne comme un proxy HTTP ou convertit un fichier HAR en simulation, et le HTTP(S) Test Script Recorder de JMeter capture le trafic du navigateur dans un plan (vérifié le 9 octobre 2026). La documentation de Gatling qualifie désormais ce Recorder de legacy, et le plus récent Gatling Studio exige un compte Enterprise pour se connecter (vérifié le 10 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

JMeter couvre davantage de protocoles en standard. Gatling fournit les principaux protocoles web plus JMS, et confie l'essentiel du reste à des composants séparés ou à des plugins communautaires.

Le README de JMeter liste tous les protocoles du tableau ci-dessus, mail compris. JDBC et JMS demandent les fichiers JAR du pilote fournis par votre base de données ou votre fournisseur JMS, et le Plugins Manager installe des plugins communautaires depuis l'interface graphique.

D'après le README de Gatling, gRPC, MQTT et GraphQL sont des composants séparés sous la Gatling Enterprise Component License, limités sans Enterprise à cinq utilisateurs simultanés et à des tests de cinq minutes. Kafka, AMQP, SFTP, FTP et JDBC passent par des plugins tiers pour Gatling 3.13 que Gatling ne maintient pas (vérifié le 9 octobre 2026).

Comment Gatling et JMeter modélisent-ils la charge ?

Gatling vous fait choisir entre un modèle ouvert et un modèle fermé dans le script lui-même. Le Thread Group classique de JMeter est un pool fermé d'utilisateurs, et une charge fondée sur les arrivées demande le plus récent Open Model Thread Group.

Dans Gatling, injectOpen accepte des taux d'arrivée comme constantUsersPerSec et rampUsersPerSec, et injectClosed des cibles de concurrence comme constantConcurrentUsers. JMeter 5.5 a ajouté l'Open Model Thread Group, que la référence marque toujours comme expérimental (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique pourquoi ce choix compte.

Comment répartir un test sur plusieurs machines ?

JMeter intègre un mode distribué. L'édition open source de Gatling génère la charge depuis une seule machine, et sa documentation indique qu'il faut un compte Gatling Enterprise pour l'exécution distribuée.

Le mode de test distant de JMeter permet à un client de piloter autant de serveurs que nécessaire. Chaque serveur exécute le plan entier : 1 000 threads sur six serveurs donnent donc 6 000 threads. Tous les nœuds devraient utiliser la même version de JMeter et de Java, RMI a besoin d'un keystore sauf si SSL est désactivé, et les fichiers de données doivent être copiés sur chaque serveur.

Il existe une troisième voie pour les plans de test JMeter. LoadFocus, l'éditeur de ce site, exécute vos plans de test JMeter existants sans modification depuis 25 régions cloud, sans serveur distant à configurer. LoadFocus n'exécute pas de simulations Gatling.

Comment s'intègrent-ils à la CI, et quels rapports obtient-on ?

Les deux tournent sans interface. Les assertions de Gatling peuvent faire échouer le build directement, alors que celles de JMeter signalent des échantillons isolés et que l'intégration CI passe par des bibliothèques tierces.

Les assertions de Gatling sont vérifiées après l'exécution, et une seule assertion en échec fait échouer la simulation et la tâche de build. Le rapport HTML montre les percentiles du temps de réponse, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde au fil du temps.

Le mode CLI de JMeter n'offre aucun critère de réussite : un objectif manqué ne fait échouer le build qu'à travers les bibliothèques pour Maven, Gradle et Jenkins que cite son README, ou une vérification de votre part. Le tableau de bord de JMeter ajoute une table APDEX, une table de statistiques avec trois percentiles configurables et des synthèses d'erreurs, et un Backend Listener envoie les résultats en direct vers InfluxDB ou Graphite.

Lequel choisir ?

Choisissez Gatling si votre équipe écrit du Java, du Kotlin, du Scala ou du TypeScript et veut relire ses tests de charge comme le reste de son code. Choisissez plutôt JMeter si vous avez besoin de protocoles au-delà du web, si vos testeurs préfèrent une interface graphique, ou si vous avez déjà des plans .jmx.

Gatling convient aux équipes qui décrivent le trafic en taux d'arrivée et veulent des règles de réussite ou d'échec à côté du scénario, avec un rapport lisible sans configuration supplémentaire.

JMeter est le meilleur choix pour tester JDBC, LDAP, FTP ou le mail, pour les testeurs qui affinent visuellement un parcours enregistré, et pour l'exécution distribuée sur vos propres serveurs sans licence commerciale. Une entreprise qui utilise déjà JMeter conserve aussi ses plans, ses plugins et son savoir-faire.

FAQ

Gatling est-il plus rapide que JMeter ? Nous ne l'avons pas mesuré nous-mêmes, nous ne désignerons donc pas de gagnant. La comparaison équitable consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Gatling peut-il exécuter des fichiers .jmx de JMeter ? Pas directement. Gatling exécute des simulations écrites avec ses SDK, donc un plan JMeter doit être réécrit. Le README de Gatling mentionne des extensions d'IA qui convertissent les plans de test JMeter, et elles demandent un jeton d'API Gatling Enterprise.

Gatling vs k6 : simulations JVM ou un seul binaire Go ?

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Gatling et k6 sont deux outils open source qui gardent les tests de charge sous forme de code dans votre dépôt, et l'un comme l'autre testera correctement une API HTTP sous charge. Choisissez Gatling si votre équipe travaille en Java, Kotlin ou Scala, ou veut un rapport HTML après chaque exécution sans rien configurer. Choisissez k6 si vous voulez un seul binaire Go sans JVM, le gRPC et les tests navigateur dès l'installation, et des seuils capables d'arrêter tôt une exécution qui échoue.

Les informations de ce comparatif Gatling vs k6 viennent de la documentation et du dépôt de chaque projet, vérifiées le 9 octobre 2026.

	Gatling	k6
Licence	Apache 2.0 ; gRPC, MQTT et GraphQL sous une licence de composant distincte (dépôt)	AGPL-3.0 (dépôt)
Environnement d'exécution	JVM ; le SDK Java demande OpenJDK LTS 11 à 25 (version 3.16.0)	Un binaire Go avec un moteur JavaScript intégré (version v2.3.0)
Scripts de test	Java, Kotlin, Scala, JavaScript ou TypeScript	JavaScript, ou TypeScript sans vérification des types
Protocoles principaux	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP/1.1, HTTP/2, WebSockets, gRPC
Modèle de charge	Profils d'injection ouverts ou fermés	Six executors, dont deux à taux d'arrivée (modèle ouvert)
Critères de réussite	Assertions, vérifiées après l'exécution	Thresholds, qui peuvent aussi interrompre une exécution en cours
Rapports	Rapport HTML après chaque exécution	Résumé en fin de test ; tableau de bord web avec export HTML
Tests navigateur	Rien d'intégré ; le Recorder transforme le trafic du navigateur en code	Module navigateur intégré (pilote un navigateur basé sur Chromium)
Montée en charge distribuée	Gatling Enterprise	k6-operator sur Kubernetes, ou Grafana Cloud k6

Quelle est la différence entre Gatling et k6 ?

La plus grande différence tient à l'environnement d'exécution. Gatling tourne sur la JVM et vous écrivez les tests avec l'un de ses SDK, alors que k6 est un programme Go compilé unique qui exécute du JavaScript.

Le README de Gatling cite un SDK Java pour Java, Kotlin et Scala, lancé par un plugin Maven, Gradle ou sbt. Son SDK JavaScript et TypeScript s'installe avec npm, et son outil en ligne de commande télécharge GraalVM : même une simulation JavaScript tourne donc sur une JVM.

k6 s'installe sous forme de paquet ou de binaire autonome, sans autre environnement d'exécution. Il exécute aussi directement les fichiers .ts, et sa prise en charge de TypeScript retire les types sans les vérifier (vérifié le 9 octobre 2026).

Comment écrire le même test dans chaque outil ?

Les deux outils peuvent exprimer le même test en JavaScript. Gatling parle de simulation et décrit la charge par un profil d'injection, k6 parle de script et la décrit par un scénario doté d'un executor.

Voici un test où dix nouveaux utilisateurs arrivent chaque seconde pendant cinq minutes, et qui échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent. Avec le SDK JavaScript de Gatling, sur le modèle de son tutoriel de première simulation :

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

Le même test dans k6, avec l'executor constant-arrival-rate :

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
}

Lancez-les avec npx gatling run et k6 run script.js.

Comment Gatling et k6 modélisent-ils la charge ?

Les deux prennent en charge les modèles de charge ouvert et fermé. Dans Gatling, le choix passe par la méthode d'injection que vous appelez, dans k6 par l'executor que vous retenez.

Dans Gatling, injectOpen prend des taux d'arrivée comme constantUsersPerSec, et injectClosed des objectifs de concurrence comme constantConcurrentUsers. k6 propose six executors : les deux à taux d'arrivée suivent le modèle ouvert, les quatre autres le modèle fermé, où un utilisateur virtuel ne lance sa prochaine itération qu'une fois la précédente terminée.

Un scénario k6 à taux d'arrivée lance ses itérations depuis un pool d'utilisateurs virtuels préalloués, et quand ce pool est épuisé, k6 saute des itérations et les compte comme itérations abandonnées (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique quand choisir l'un ou l'autre.

Comment Gatling et k6 décident-ils si un test a réussi ?

Les deux transforment des objectifs de performance en un verdict, réussite ou échec, qu'un pipeline CI peut exploiter. Gatling vérifie ses objectifs une fois l'exécution terminée, et k6 peut en plus arrêter une exécution dès qu'un objectif est manqué.

Les assertions de Gatling sont évaluées après la simulation, et une seule assertion en échec fait échouer la simulation et le build. Les thresholds de k6 terminent une exécution en échec avec un code de sortie non nul, et un threshold réglé avec abortOnFail arrête le test dès qu'il échoue (vérifié le 9 octobre 2026).

Quels protocoles et quels tests navigateur chaque outil couvre-t-il ?

Les deux gèrent HTTP et WebSockets dès l'installation. Gatling y ajoute Server-Sent Events et JMS, et k6 le gRPC et de vraies sessions de navigateur.

Selon le README de Gatling, gRPC, MQTT et GraphQL sont des composants distincts sous la Gatling Enterprise Component License, limités sans Enterprise à cinq utilisateurs simultanés et à des tests de cinq minutes. k6 cite HTTP/1.1, HTTP/2, WebSockets et gRPC comme protocoles intégrés, et d'autres s'ajoutent via des extensions xk6 comme Kafka et Redis.

Pour les tests navigateur, k6 dispose d'un module navigateur qui pilote un navigateur basé sur Chromium et collecte des métriques côté frontend. La documentation de Gatling ne décrit aucun moteur de navigateur : le Recorder de Gatling transforme une session de navigateur ou un fichier HAR en simulation au niveau HTTP (vérifié le 9 octobre 2026).

Comment lancer un test plus gros que ce qu'une machine peut générer ?

L'édition open source de Gatling génère la charge depuis une seule machine, et l'exécution distribuée demande Gatling Enterprise. k6 peut répartir un test sur un cluster Kubernetes avec le k6-operator open source, ou le lancer sur Grafana Cloud k6.

Le guide d'installation de Gatling demande un compte Enterprise pour l'exécution distribuée, qui s'appuie sur des générateurs de charge gérés ou sur des emplacements privés dans votre propre compte AWS, Azure, GCP ou Kubernetes. Le k6-operator répartit un test sur plusieurs instances k6 dans un cluster (vérifié le 9 octobre 2026).

Il existe une troisième voie pour les scripts k6. LoadFocus, l'éditeur de ce site, exécute les scripts k6 sur sa propre infrastructure cloud depuis 25 régions, avec le nombre d'utilisateurs et la durée pris dans les réglages du test. Son validateur de script prévient que les scénarios à taux d'arrivée y tournent avec un nombre fixe d'utilisateurs : un script en modèle ouvert comme celui ci-dessus ne tient donc pas son taux d'arrivée sur LoadFocus. LoadFocus n'exécute pas les simulations Gatling : pour Gatling, la voie vers plus de machines reste Gatling Enterprise.

Quels rapports obtenez-vous ?

Gatling écrit un rapport HTML après chaque exécution, sans configuration. k6 affiche un résumé dans le terminal et peut produire un rapport HTML depuis son tableau de bord web intégré.

Le rapport HTML de Gatling trace les percentiles du temps de réponse, les utilisateurs lancés par seconde et les requêtes par seconde au fil du test. k6 affiche un résumé de fin de test, et son tableau de bord web montre des graphiques en direct et exporte un rapport HTML autonome quand vous définissez K6_WEB_DASHBOARD_EXPORT.

Lequel choisir ?

Gatling convient aux équipes qui vivent sur la JVM, et k6 à celles qui veulent un binaire unique et du JavaScript. Les protocoles, les tests navigateur et la montée en charge tranchent la plupart des autres cas.

Choisissez Gatling plutôt que k6 si votre équipe vit sur la JVM et veut des tests en Java, Kotlin ou Scala construits avec Maven, Gradle ou sbt à côté du code de l'application, si vous avez besoin de JMS ou de Server-Sent Events, ou si vous voulez un rapport HTML après chaque exécution sans configuration.

Choisissez k6 plutôt que Gatling si vous voulez un binaire unique en CI sans JVM à installer, si vos tests ont besoin de gRPC ou de vraies sessions de navigateur, si des thresholds doivent arrêter tôt une exécution qui échoue, ou si vous comptez monter en charge sur Kubernetes avec un operator open source.

FAQ

Gatling est-il plus rapide que k6 ? Nous ne l'avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. La seule comparaison honnête consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Gatling peut-il exécuter des scripts k6 ? Pas d'après la documentation de Gatling, qui ne décrit aucun moyen d'exécuter des scripts k6. Les deux SDK ont des API différentes et les convertisseurs de Gatling couvrent JMeter et LoadRunner : un script k6 doit donc être réécrit en simulation Gatling, même avec le SDK JavaScript.

LoadFocus peut-il exécuter des tests Gatling ? Non. LoadFocus exécute des scripts k6 et des plans de test JMeter. Pour répartir une simulation Gatling sur plusieurs machines, utilisez Gatling Enterprise.

Test de charge d'une API GraphQL : guide pratique

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Pour un test de charge d'une API GraphQL, scriptez les opérations que vos clients envoient vraiment, donnez à chacune son propre nom dans l'outil de test et mélangez-les dans les proportions observées en production, avec des variables variées. Vérifiez dans chaque corps de réponse la présence d'un tableau errors, car un serveur GraphQL répond le plus souvent avec un statut HTTP 200 même quand une partie de l'opération a échoué. Augmentez ensuite la charge et jugez chaque opération sur ses propres percentiles.

Sources : graphql.org, le brouillon de la spécification GraphQL over HTTP et la documentation de chaque outil, le tout vérifié le 9 octobre 2026.

Outil	Nommer chaque opération avec	Faire échouer une réponse qui contient `errors`	Alimenter les variables depuis
k6	`tags: { name: "..." }`	Un `check()` sur le corps analysé	`SharedArray`
JMeter	Le nom du sampler	Une JSON Assertion sur `$.errors`, inversée	CSV Data Set Config
Gatling	`http("...")` ou le plugin GraphQL	`jsonPath("$.errors").notExists()`	Les feeders
Artillery	Un `name` sur la requête	`notHasProperty: "errors"`	`config.payload`

Pourquoi une API GraphQL demande-t-elle un test de charge différent ?

Parce que toutes les opérations passent par une seule URL et que le travail derrière dépend du document GraphQL et de ses variables. Un rapport groupé par URL met dans le même panier une recherche coûteuse et une simple lecture.

Le guide Serving over HTTP de graphql.org indique qu'un serveur GraphQL fonctionne sur un seul endpoint, en général /graphql. Les opérations y arrivent en POST, avec un corps JSON qui contient query, un operationName facultatif et variables.

Comment obtenir des résultats par opération ?

Nommez chaque requête d'après son opération GraphQL et faites regrouper les statistiques par ce nom. Chaque outil a son propre réglage pour cela (vérifié le 9 octobre 2026).

k6 : le guide sur les tags et les groupes conseille de définir tags.name pour donner un nom parlant à une requête, et les thresholds peuvent cibler un seul tag, par exemple http_req_duration{name:GetProduct}.
JMeter : l'Aggregate Report crée une ligne par requête portant un nom différent. Depuis JMeter 5.4, le sampler GraphQL HTTP Request a des champs Query, Variables et Operation Name.
Gatling : le nom de la requête sert de clé à ses statistiques, et le plugin GraphQL nomme les requêtes d'après l'opération, par exemple query GetUser.
Artillery : le plugin metrics-by-endpoint rapporte les résultats par URL et ajoute à chaque entrée le name de la requête, si bien que les opérations nommées apparaissent séparément ; useOnlyRequestNames: true retire l'URL et ne garde que le nom.

Quelles opérations le test doit-il envoyer ?

Celles que reçoit la production, dans les mêmes proportions. Relevez le nombre de chaque opération dans vos logs serveur ou votre monitoring GraphQL et transformez-le en un mélange pondéré de lectures et de mutations.

Utilisez les documents que vos clients embarquent, avec leur vraie profondeur, plutôt qu'un seul document simplifié. Alimentez les variables depuis un fichier, pour que le serveur cherche beaucoup d'enregistrements différents au lieu de renvoyer un seul résultat en cache. Gardez aussi un nombre réaliste d'opérations distinctes : la note technique d'Apollo sur le test de charge GraphQL, un document du fournisseur, explique que chaque nouvelle opération est analysée et validée avant d'être exécutée, et déconseille de générer bien plus d'opérations uniques que n'en envoient les vrais clients.

Les mutations modifient les données : lancez-les là où vous pouvez les réinitialiser. Le guide pas à pas du test de charge couvre les objectifs et la montée en charge.

Pourquoi une réponse HTTP 200 peut-elle quand même être un échec ?

Parce que GraphQL signale les erreurs dans le corps de la réponse. Une requête peut renvoyer le statut 200 avec un tableau errors et des données partielles, et un contrôle du statut la laisse passer.

La page Response de graphql.org explique que, quand un resolver échoue, l'exécution continue et la réponse contient data à côté de errors. Son guide HTTP ajoute qu'une telle réponse doit tout de même recevoir un statut 2xx, faute de code HTTP pour un succès partiel, et que certains anciens serveurs répondent 2xx même pour des erreurs de validation. Le brouillon GraphQL over HTTP propose un statut spécifique 294 pour le succès partiel avec le type de média plus récent application/graphql-response+json.

Dans un test de charge, c'est doublement trompeur. Les erreurs ne sont pas comptées, et les requêtes qui échouent vite, comme des opérations refusées par une limite de profondeur, tirent les temps de réponse vers le bas.

Comment vérifier le tableau errors dans chaque outil ?

Analysez le corps JSON et faites échouer la requête quand errors est présent. Chaque outil a un moyen intégré de le faire.

Dans k6, un check sur le corps analysé s'en charge, et un threshold sur la métrique checks fait échouer l'exécution, car les checks seuls ne changent pas le code de sortie de k6 :

import http from "k6/http";
import { check, sleep } from "k6";
import { SharedArray } from "k6/data";

const URL = "https://staging.example.com/graphql";
const ids = new SharedArray("ids", () =>
  JSON.parse(open("./product-ids.json")));
const QUERY = `query GetProduct($id: ID!) {
  product(id: $id) { id name price }
}`;

export const options = {
  vus: 20,
  duration: "5m",
  thresholds: {
    checks: ["rate>0.99"],
    "http_req_duration{name:GetProduct}": ["p(95)<400"],
  },
};

function parse(res) {
  try { return res.json(); } catch (e) { return null; }
}

export default function () {
  const id = ids[Math.floor(Math.random() * ids.length)];
  const payload = JSON.stringify({
    query: QUERY,
    operationName: "GetProduct",
    variables: { id: id },
  });
  const res = http.post(URL, payload, {
    headers: { "Content-Type": "application/json" },
    tags: { name: "GetProduct" },
  });
  const body = parse(res);
  check(res, {
    "status is 2xx": (r) => r.status >= 200 && r.status < 300,
    "no GraphQL errors": () => body !== null && !body.errors,
  });
  sleep(1);
}

SharedArray charge les identifiants une seule fois pour tous les utilisateurs virtuels. Le try évite qu'un corps qui n'est pas du JSON, comme la page d'erreur d'un proxy, interrompe l'itération.

Dans JMeter, ajoutez une JSON Assertion avec le chemin $.errors et cochez "Invert assertion", pour que l'échantillon échoue quand le chemin existe. Un JSON Extractor copie des identifiants dans des variables pour l'opération suivante.

Dans Gatling, ajoutez .check(jsonPath("$.errors").notExists()), deux éléments tirés de sa référence des checks. Le plugin GraphQL vérifie le statut et les erreurs par défaut, mais sa page d'installation limite les exécutions avec la Community Edition à 5 utilisateurs et 5 minutes (vérifié le 9 octobre 2026). Pour des tests plus gros sans Gatling Enterprise, utilisez des requêtes HTTP classiques avec ce check.

Dans Artillery, le plugin expect propose notHasProperty: "errors", et reportFailuresAsErrors: true fait apparaître les attentes non remplies dans le rapport. Un capture avec un chemin json transmet une valeur à la requête suivante.

Que surveiller en plus des temps de réponse ?

Le cache, les requêtes persistées et la charge de la base de données par requête HTTP. Chacun peut rendre un test plus rapide ou plus lent que la production pour des raisons sans rapport avec la capacité.

Le guide de performance de graphql.org note que les opérations de type query envoyées en GET peuvent profiter du cache HTTP et des CDN, et que les requêtes persistées permettent à un client d'envoyer un hash au lieu du document complet. Si vos clients le font, le test doit le faire aussi. S'ils ne le font pas, un test qui répète la même query avec les mêmes variables mesure un cache que le trafic réel ne sollicite pas. La note technique d'Apollo ajoute qu'Apollo Server, Gateway et le GraphOS Router activent par défaut les requêtes persistées automatiques.

Le même guide décrit le problème N+1 : une liste dont le resolver charge chaque élément séparément transforme une requête en de nombreuses requêtes à la base, ce que l'on corrige en général en les regroupant avec un outil comme DataLoader. Suivez les requêtes à la base par seconde à côté des requêtes HTTP par seconde ; si elles grimpent beaucoup plus vite quand la charge monte, soupçonnez un resolver. Les limites de profondeur, de complexité et de débit peuvent aussi se déclencher pendant un test.

D'où doit venir la charge ?

D'une seule machine tant que vous écrivez le script et faites un smoke test, puis du cloud quand il vous faut plus de charge ou du trafic venant de plusieurs régions.

LoadFocus exécute des scripts k6 depuis 25 régions cloud. Le nombre d'utilisateurs et la durée y viennent des paramètres du test et non des options du script, et les scénarios à taux d'arrivée tournent avec un nombre fixe d'utilisateurs au lieu d'une cadence de requêtes fixe, la différence expliquée dans l'article sur le modèle de charge ouvert ou fermé. LoadFocus publie aussi un modèle pour les endpoints GraphQL avec des requêtes complexes (en anglais).

FAQ

Un test de charge GraphQL doit-il envoyer les queries en GET ou en POST ? Comme le font vos clients. graphql.org n'autorise GET que pour les opérations de type query, et les mutations doivent passer par POST. Si la production envoie des requêtes persistées en GET via un CDN, testez aussi ce chemin.

Le même script peut-il tester la charge des subscriptions GraphQL ? En général non. graphql.org rappelle que les subscriptions durent longtemps et passent souvent par des WebSockets ou des server-sent events : elles demandent leur propre scénario, dans un outil qui gère ce transport.

Une réponse partielle doit-elle compter comme une requête en échec ? Dans la plupart des tests, oui, car le client a reçu une erreur pour une partie de sa demande. Si certaines erreurs sont attendues, comme des résultats introuvables pour des enregistrements supprimés, ciblez ces codes d'erreur et faites échouer le reste.

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

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

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.

Outil	Écrit en	Licence	Contrôle de la cadence	HTTP/2	Dernière version
wrk	C, scripts LuaJIT	Modified Apache 2.0	Aucun	Non documenté	Tag 4.2.0, févr. 2021
wrk2	C	Apache 2.0	Cadence fixe (`-R`)	Non documenté	Aucune, dernier commit sept. 2019
hey	Go	Apache 2.0	Limite par worker (`-q`)	Oui	v0.1.5, janv. 2026
oha	Rust	MIT	Limite globale (`-q`)	Oui, plus HTTP/3	v1.16.0, août 2026
ab	C (Apache httpd)	Apache 2.0	Aucun	Non	httpd 2.4.69, oct. 2026
bombardier	Go	MIT	Limite (`-r`)	Oui	v2.0.2, mars 2025
autocannon	Node.js	MIT	Limite (`-R`)	Non	v8.0.0, oct. 2024
h2load	C++ (nghttp2)	MIT	Par client (`--rps`)	Oui, plus HTTP/3	nghttp2 v1.70.0, juil. 2026
Vegeta	Go	MIT	Cadence fixe (`-rate`)	Oui	v12.13.0, oct. 2025

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.

Loi de Little en test de charge : dimensionner et vérifier

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

La loi de Little en test de charge dit que le nombre moyen d'utilisateurs ou de requêtes présents dans un système est égal au rythme auquel ils le traversent multiplié par le temps moyen que chacun y passe : L = λW. Avec un nombre fixe d'utilisateurs virtuels, cela donne utilisateurs = boucles par seconde × (temps de réponse + temps de réflexion), ce qui indique avant un test si le plan peut atteindre son taux cible et, après, si les résultats se tiennent. Elle porte sur des moyennes calculées sur une phase stable du test, donc elle ne dit rien des percentiles.

Les exemples chiffrés ci-dessous sont de simples calculs, sans test derrière. Les faits sur les outils viennent de la documentation de chaque projet, vérifiée le 9 octobre 2026.

Terme	Définition de Little	Utilisateurs virtuels fixes (modèle fermé)	Taux d'arrivée (modèle ouvert)
L	Nombre moyen d'éléments dans le système	Utilisateurs virtuels, en attente ou en pause	Itérations en cours
λ	Taux d'arrivée moyen	Boucles terminées par seconde	Le taux que vous fixez
W	Temps moyen passé à l'intérieur	Temps de réponse + temps de réflexion par boucle	Durée d'une itération

Que dit la loi de Little ?

Sur la durée, le nombre moyen d'éléments dans un système de files d'attente est égal à leur taux d'arrivée moyen multiplié par le temps moyen que chacun y passe. Connaissez deux des trois grandeurs et vous obtenez la troisième.

John D. C. Little a publié la démonstration en 1961 dans Operations Research sous le titre A Proof for the Queuing Formula: L = λW. Dans son bilan pour les 50 ans de la loi, paru en 2011, il écrit qu'elle tient dans des conditions remarquablement générales : pour une seule file comme pour un réseau entier, pour une sous-catégorie d'éléments comme pour l'ensemble, et quel que soit l'ordre de service. Le même article transpose les termes à un serveur : requêtes en cours de traitement, requêtes par seconde et temps de réponse moyen.

Que représentent L, λ et W dans un test de charge ?

Cela dépend de l'endroit où vous tracez la frontière du système. Autour du serveur, L est le nombre de requêtes en cours et W le temps de réponse ; autour de la boucle complète d'un utilisateur virtuel, L est le nombre total d'utilisateurs virtuels et W le temps de réponse plus le temps de réflexion.

Dans un test en modèle fermé, chaque utilisateur se trouve toujours quelque part dans sa boucle : il attend une réponse ou marque une pause entre deux étapes. Avec la frontière autour de la boucle, tous comptent comme « dans le système », λ est le rythme auquel les boucles se terminent et W la durée moyenne d'une boucle, y compris le temps de réflexion ajouté par le script :

utilisateurs = boucles/s × (temps de réponse + réflexion)

Autour du serveur, la même loi donne les requêtes en vol : requêtes par seconde × temps de réponse moyen, le nombre que vos pools de connexions et vos threads de travail doivent absorber. Gardez les trois valeurs sur la même frontière et la même tranche de temps ; les mélanger donne des résultats faux mais plausibles.

Comment dimensionner un test en modèle fermé avec la loi de Little ?

Convertissez le taux de requêtes visé en boucles par seconde, puis multipliez par la durée attendue d'une boucle : le résultat est le nombre d'utilisateurs virtuels dont le plan a besoin. Prenez le temps de réponse attendu sous la charge cible, en général plus élevé que celui observé avec quelques utilisateurs.

Un exemple chiffré, purement arithmétique. L'objectif est de 100 requêtes par seconde, chaque boucle envoie 4 requêtes censées durer 0,5 seconde chacune, et le script marque 3 pauses de 2 secondes en moyenne :

boucles par seconde   = 100 requêtes/s ÷ 4 requêtes = 25
durée d'une boucle    = 4 × 0,5 s + 3 × 2 s          = 8 s
utilisateurs virtuels = 25 boucles/s × 8 s           = 200

Voyez 200 comme un minimum. Si les réponses prennent 1 seconde sous cette charge, une boucle dure 10 secondes et le même objectif demande 250 utilisateurs.

Pourquoi les mêmes utilisateurs envoient-ils moins de requêtes quand le système ralentit ?

Le nombre d'utilisateurs est fixe, donc quand la durée d'une boucle augmente, le nombre de boucles par seconde doit baisser. La charge diminue au moment précis où le système commence à peiner.

Gardez les 200 utilisateurs et faites durer chaque requête 2 secondes. Une boucle dure alors 4 × 2 + 6 = 14 secondes, et 200 ÷ 14 donne environ 14,3 boucles, soit environ 57 requêtes par seconde. Le test affiche toujours 200 utilisateurs, mais il tourne à un peu plus de la moitié du taux prévu. L'article sur le modèle de charge ouvert ou fermé explique pourquoi cela masque la saturation ; la loi de Little prédit l'ampleur de la baisse.

Elle montre aussi à quoi ressemble une limite de capacité. Quand le taux de requêtes ne peut plus monter, chaque utilisateur supplémentaire n'ajoute que de l'attente : avec un plafond de 25 boucles par seconde, 300 utilisateurs donnent 12 secondes par boucle et 400 utilisateurs 16. Le graphique LoadFocus temps de réponse vs utilisateurs virtuels trace le temps de réponse moyen et maximal en fonction du nombre d'utilisateurs virtuels actifs, un point par palier atteint ; c'est là qu'apparaît cette montée régulière.

Comment vérifier un test terminé avec la loi de Little ?

Prenez le taux de requêtes et le temps de réponse moyens sur une période où le nombre d'utilisateurs est resté stable, recalculez-en le nombre d'utilisateurs et comparez-le à votre configuration. Un écart important signifie qu'une partie du temps échappe à vos mesures.

Un autre calcul. Un test maintient 200 utilisateurs et affiche 80 requêtes par seconde pour 0,6 seconde en moyenne, avec les mêmes 4 requêtes et 6 secondes de pause par boucle. Cela fait 20 boucles par seconde de 4 × 0,6 + 6 = 8,4 secondes chacune, de quoi occuper 168 utilisateurs. Les 32 autres signifient que chaque boucle a en réalité duré 10 secondes, donc environ 1,6 seconde par boucle reste inexpliquée. Où chercher :

L'établissement des connexions. Dans k6, http_req_duration n'inclut ni la résolution DNS ni la connexion (référence des métriques, vérifiée le 9 octobre 2026).
Le générateur de charge. Un générateur surchargé retarde le script entre deux requêtes.
Le temps de réflexion. Des pauses aléatoires peuvent durer en moyenne plus que prévu.
La fenêtre. Si elle empiète sur une rampe, moins d'utilisateurs étaient actifs en moyenne.

k6 mesure aussi la boucle directement : vus compte les utilisateurs virtuels actifs et iteration_duration la durée d'une itération complète, donc les utilisateurs actifs doivent être proches des itérations par seconde × la durée moyenne d'une itération.

Et les tests par taux d'arrivée ?

La loi tient avec la frontière autour de chaque itération : les itérations en cours sont égales au taux d'arrivée multiplié par la durée d'une itération. C'est le nombre d'utilisateurs virtuels que l'outil doit garder prêts.

Le guide k6 sur l'allocation des VU pour les exécuteurs à taux d'arrivée les estime à la durée médiane d'une itération × le taux, plus une constante pour la variance (vérifié le 9 octobre 2026). C'est la loi de Little avec la médiane à la place de la moyenne ; quelques itérations lentes tirent la moyenne au-dessus de la médiane, d'où l'importance de la marge.

LoadFocus exécute des scripts k6 dans son cloud, et les scénarios à taux d'arrivée y tournent avec un nombre fixe d'utilisateurs ; le validateur de script le signale quand vous ajoutez un tel script. Dimensionnez ces tests avec le calcul du modèle fermé ci-dessus et attendez-vous à voir le taux baisser si les réponses ralentissent.

Où la loi de Little cesse-t-elle de s'appliquer ?

Elle relie des moyennes sur une période où le système est à l'équilibre. Les percentiles, les fenêtres courtes et les rampes sortent de son champ.

Des moyennes seulement. Un test peut respecter la loi alors qu'une requête sur vingt attend dix fois la moyenne ; jugez donc aussi les résultats sur les percentiles.
Une phase stable. La démonstration de 1961 suppose un processus stationnaire, et le bilan de 2011 montre que la formule est aussi exacte sur une fenêtre finie qui commence et finit à vide. Un plateau de test n'est ni l'un ni l'autre, alors choisissez-en un long, où les utilisateurs qui terminent une boucle sont aussi nombreux que ceux qui en commencent une.
Les rampes. Pendant l'ajout d'utilisateurs, le pic configuré n'est pas L : prenez le nombre moyen d'utilisateurs sur la fenêtre, ou laissez la rampe de côté.
Les erreurs. Les échecs rapides comptent comme des requêtes terminées avec un temps court, si bien qu'un système défaillant peut quand même équilibrer l'équation. Vérifiez d'abord le taux d'erreur.

FAQ

La loi de Little suppose-t-elle des arrivées de Poisson ou une file particulière ? Non. Les démonstrations du bilan de Little ne supposent rien sur la forme des arrivées ni sur les temps de service, et le résultat tient quel que soit l'ordre de service. Il faut seulement que les moyennes existent sur la période mesurée.

La loi de Little peut-elle prédire le temps de réponse p95 ? Non. Elle relie trois moyennes, elle peut donc vérifier un temps de réponse moyen, mais elle ne dit rien de la forme de la distribution ni des quelques pour cent les plus lents.

Critères de réussite d'un test de charge : comment les fixer

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Les critères de réussite d'un test de charge sont les quelques seuils qu'une exécution doit tenir pour être déclarée réussie : un percentile de latence pour les requêtes que les utilisateurs attendent, un taux d'erreur et un taux de requêtes minimal, le tout à une charge donnée. Tirez ces seuils d'un objectif de niveau de service (SLO), placez à l'intérieur des seuils de régression issus d'exécutions précédentes, et laissez le code de sortie de l'outil faire échouer l'exécution sur ces seuils stricts uniquement. Tout le reste est un avertissement qu'une personne lit.

Les informations sur les outils ont été vérifiées le 9 octobre 2026 dans la documentation de chaque projet, et chaque seuil présenté est un exemple.

Critère	Seuil d'exemple	Origine du chiffre	En cas d'écart
p95 de latence, paiement	Moins de 400 ms	SLO de latence moins une marge	Échec
p99 de latence, paiement	Moins de 1 200 ms	Exécutions précédentes de ce test	Avertissement
Taux d'erreur	Moins de 0,5 %	SLO de disponibilité	Échec
Requêtes par seconde	Au moins 95 % du plan	La charge prévue	Échec
CPU du générateur de charge	Moins de 80 %	Outil ou plateforme	Exécution invalide

Qu'est-ce qui fait réussir ou échouer un test de charge ?

Une exécution réussit quand chaque seuil strict tient à la charge prévue, et échoue dès qu'un seuil est manqué. Elle est invalide quand le test lui-même n'a pas fait son travail, quels que soient les chiffres.

Un générateur de charge saturé, une charge qui n'a jamais atteint sa cible ou un script en erreur produisent des chiffres sur le dispositif de test. LoadFocus, par exemple, affiche un avertissement de saturation du générateur de charge quand un moteur a atteint ou dépassé 80 % de CPU en pointe. Les codes de sortie de k6 séparent les cas pour la CI : 99 signale des seuils non tenus, 107 une exception dans le script (vérifié le 9 octobre 2026).

Comment transformer un SLO en critères de test de charge ?

Reformulez chaque SLO que la charge peut mettre en défaut, en général la latence et la disponibilité, en seuil sur ce que le test mesure, et rendez ce seuil plus strict que le SLO pour qu'une réussite laisse de la marge.

Le livre SRE de Google définit un SLO comme une valeur cible ou une plage de valeurs pour un niveau de service mesuré par un indicateur (SLI), avec des exemples comme : 99 % des appels Get se terminent en moins de 100 ms. Il demande qu'un SLO précise comment il est mesuré et dans quelles conditions il s'applique, et recommande une marge de sécurité : un objectif interne plus strict que celui annoncé aux utilisateurs.

Pour un test de charge, ces conditions sont la charge et le mélange de requêtes. « 95 % des appels de paiement en moins de 500 ms » pourrait ainsi devenir, à titre d'exemple, « p95 du paiement sous 400 ms à 300 requêtes par seconde pendant 15 minutes ». Sans SLO, convenez d'un objectif provisoire avec le responsable produit.

Quelles métriques les critères doivent-ils couvrir ?

La latence des requêtes que les utilisateurs attendent, un taux d'erreur, le taux de requêtes atteint et, surtout sous forme d'avertissements, les ressources des serveurs.

La latence par type de requête. Un percentile global mélange un health check rapide et une recherche lente. Dans k6, les requêtes étiquetées créent des sous-métriques avec leurs propres seuils ; dans Gatling, details() cible une requête ou un groupe. Un test qui a freiné sa propre charge affiche des percentiles flatteurs (coordinated omission).
Les erreurs, au sens large. Un 200 rapide qui renvoie une page d'erreur reste un échec : vérifiez le contenu. Une Response Assertion JMeter en échec marque son échantillon comme non réussi ; les checks k6 n'agissent sur le code de sortie qu'à travers un seuil.
Un plancher de taux de requêtes. Dans un modèle de charge fermé, un système lent reçoit moins de requêtes, et une exécution peut tenir ses seuils de latence avec une fraction de la charge prévue (modèle de charge ouvert ou fermé).
Les ressources des serveurs. CPU, mémoire et occupation des pools viennent de votre supervision. Traitez-les comme des avertissements, sauf si un plan de capacité fixe un plafond strict.

Comment choisir les chiffres ?

Le plafond vient du SLO, le seuil de régression des exécutions précédentes du même test. Le SLO dit ce que les utilisateurs tolèrent ; les exécutions précédentes disent ce que ce build fait d'habitude.

Le livre SRE déconseille de fixer un SLO à partir des performances actuelles. Un seuil de régression sert à repérer un changement, et les performances actuelles sont justement sa matière première. Lancez plusieurs fois le build inchangé avec le même environnement et la même charge, notez de combien chaque métrique varie, et placez le seuil au-dessus de la pire exécution avec un peu de marge, tout en restant sous le plafond tiré du SLO quand il y en a un.

Si les exécutions d'un même build varient davantage que la régression que vous voulez détecter, le test est trop bruité pour bloquer un build : allongez d'abord la phase stable ou isolez l'environnement. Enregistrez de nouvelles exécutions de référence après tout changement volontaire.

Quels critères doivent faire échouer le build, et lesquels seulement avertir ?

Faites échouer le build sur les seuils issus d'un SLO ou qui vérifient l'exactitude des réponses. Avertissez sur les percentiles de queue, l'usage des ressources et les dérives lentes, qui demandent du jugement ; une barrière qui échoue sur du bruit finit vite désactivée.

Le plugin ensure d'Artillery a un niveau d'avertissement : une condition avec strict: false est facultative, et un échec ne change donc pas le code de sortie (vérifié le 9 octobre 2026). Dans k6, un check sans seuil ne fait jamais échouer l'exécution. Ailleurs, gardez les avertissements hors des assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Quand un test de charge doit-il s'arrêter plus tôt ?

Quand continuer ne peut que nuire ou ne prouve plus rien : des erreurs bien au-delà du seuil, un système déjà tombé ou un générateur qui ne suit plus. Donnez à la règle un délai de grâce pour que le bruit du démarrage ne la déclenche pas.

Rendez les règles d'arrêt plus lâches que les seuils de réussite : elles protègent un environnement partagé. Dans k6, abortOnFail arrête le test dès qu'un seuil échoue, après un delayAbortEval facultatif. La documentation de Locust sur les extensions montre un greenlet en arrière-plan qui arrête l'exécution quand le taux d'échec dépasse un seuil. Dans Gatling, crashLoadGeneratorIf arrête le générateur avec un code d'échec quand une condition est vraie dans la session d'un utilisateur virtuel. Un Thread Group JMeter peut arrêter le test sur une erreur de sampler, ce qui convient à un contrôle d'exactitude (tout vérifié le 9 octobre 2026).

Comment chaque outil encode-t-il les critères ?

k6 et Artillery transforment un seuil strict manqué en code de sortie non nul, Locust le fait pour toute requête en échec ou pour les seuils que vous codez vous-même, et les assertions de Gatling font échouer le build. JMeter laisse le verdict à une étape qui suit l'exécution.

k6 : les seuils se placent dans les options du script. Cet exemple échoue sur le p95 des requêtes étiquetées name: checkout ou sur 0,5 % d'erreurs, et s'arrête au bout d'une minute si les erreurs dépassent 5 % :

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling : les assertions associent une portée (global, forAll, details), une statistique comme un percentile ou requestsPerSec, et une condition. Elles sont évaluées après l'exécution, et une seule assertion en échec fait échouer la simulation.

Locust se termine avec le code 1 si au moins une requête a échoué, et --exit-code-on-error change ce code. Pour un ratio ou un percentile, définissez environment.process_exit_code dans un listener quitting ; le code source de Locust donne la priorité à cette valeur.

JMeter juge chaque échantillon avec ses assertions, et ses options en ligne de commande ne prévoient aucun seuil pour l'exécution entière. C'est la CI qui tranche : un court script sur le fichier de résultats, comme dans notre guide GitHub Actions, ou le jmeter-maven-plugin, un plugin tiers dont le goal results fait échouer le build si un seul échantillon a échoué, sauf si errorRateThresholdInPercent fixe un taux (vérifié le 9 octobre 2026).

LoadFocus juge les exécutions selon des seuils de réussite ou d'échec enregistrés sur le test : temps de réponse p95 et p99 maximaux, taux d'erreur maximal et taux de requêtes minimal, chacun facultatif. Chaque exécution reçoit un badge PASS ou FAIL avec les valeurs mesurées et les cibles, et une API transmet le verdict à un pipeline. LoadFocus exécute les scénarios k6 à taux d'arrivée avec un nombre fixe d'utilisateurs : là, un plancher de taux vérifie donc ce que ces utilisateurs ont atteint.

FAQ

Le temps de réponse moyen doit-il être un critère de réussite ? Rarement. Le livre SRE préfère les percentiles : une moyenne masque la longue traîne et peut rester stable pendant que les requêtes les plus lentes ralentissent nettement.

Combien de critères de réussite un test de charge doit-il avoir ? Une poignée de seuils stricts, plus des avertissements. Le livre SRE conseille d'avoir le moins de SLO possible et estime qu'un SLO qu'on ne peut jamais invoquer pour gagner une discussion sur les priorités ne vaut probablement pas la peine d'être gardé. Appliquez la même règle à chaque seuil d'un test de charge.

Un test de charge peut-il réussir avec quelques requêtes en échec ? Oui, si le taux d'erreur reste sous son seuil. Vérifiez le comportement par défaut de votre outil : Locust fait échouer l'exécution à la moindre requête en échec.

Test de charge dans GitHub Actions : guide pratique

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Pour un test de charge dans GitHub Actions, un seul fichier de workflow suffit : installer l'outil, lancer un test court contre une URL de préproduction et laisser le code de sortie de l'outil faire échouer le job quand un seuil n'est pas tenu. Envoyez les résultats comme artefact pour que chaque exécution laisse une trace. Gardez un test modeste, car un runner standard hébergé par GitHub est une seule machine virtuelle avec quelques cœurs de CPU.

Les informations sur les outils et sur GitHub viennent de la documentation de chaque éditeur, vérifiées le 9 octobre 2026, et les workflows suivent cet usage documenté.

Outil	Installé par	Ce qui fait échouer le job	Résultats à conserver
k6	`setup-k6-action` de Grafana	Un seuil non tenu	Sortie JSON
Artillery	`artilleryio/action-cli`	Une vérification `ensure` en échec	`report.json`
Locust	`pip install locust`	Toute requête en échec, ou votre propre règle	Fichiers CSV et HTML
JMeter	L'archive de la version	Rien d'intégré : ajouter une étape de contrôle	Fichier `.jtl` et rapport HTML

De quoi un workflow de test de charge a-t-il besoin ?

D'un déclencheur, d'un runner, d'une étape qui installe l'outil, d'une étape qui lance le test avec des seuils et d'une étape qui envoie les résultats. Tout le reste est facultatif.

Gardez le script de test dans le dépôt, par exemple sous tests/load/. Lisez l'URL de préproduction depuis une variable du dépôt via le contexte vars, et fixez timeout-minutes sur le job : la valeur par défaut est de 360 minutes (vérifié le 9 octobre 2026).

Quels événements doivent déclencher un test de charge ?

Lancez un test court sur les pull requests et un test plus long selon un planning ou à la main.

Utilisez pull_request pour repérer une régression avant la fusion, workflow_dispatch pour les exécutions manuelles et schedule pour des exécutions cron (en UTC, sauf si vous indiquez un fuseau horaire). La référence des événements de GitHub ajoute quelques limites (vérifié le 9 octobre 2026) : les exécutions planifiées ne tournent que sur la branche par défaut, au plus toutes les cinq minutes, et peuvent être retardés en début d'heure. Les pull requests venant de forks ne reçoivent aucun secret hormis GITHUB_TOKEN.

Comment lancer k6 dans GitHub Actions ?

Utilisez les deux actions officielles de Grafana, l'une pour installer k6, l'autre pour lancer le script. L'étape échoue dès que k6 se termine avec un code de sortie non nul, ce que provoque un seuil non tenu.

setup-k6-action et run-k6-action sont toutes deux en v1 (vérifié le 9 octobre 2026) :

name: load-test
on:
  pull_request:
  workflow_dispatch:

jobs:
  k6:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    env:
      BASE_URL: ${{ vars.STAGING_URL }}
    steps:
      - uses: actions/checkout@v7
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: tests/load/smoke.js
          flags: --out json=results.json
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: k6-results
          path: results.json
          retention-days: 14

Les seuils se trouvent dans le script, qui lit BASE_URL dans l'environnement :

import http from "k6/http";

export const options = {
  vus: 10,
  duration: "1m",
  thresholds: {
    http_req_failed: ["rate<0.01"],
    http_req_duration: ["p(95)<500"],
  },
};

export default function () {
  http.get(`${__ENV.BASE_URL}/health`);
}

La documentation de k6 précise que les checks n'ont pas d'effet sur le code de sortie, si bien que la décision de réussite ou d'échec doit venir des seuils.

Comment lancer Artillery, Locust ou JMeter à la place ?

Remplacez les étapes d'installation et d'exécution, gardez le reste du workflow et servez-vous du mécanisme propre à chaque outil pour échouer quand un objectif est manqué.

Artillery dispose d'une GitHub Action officielle dont le README indique que @v2 suit la dernière version 2.x (vérifié le 9 octobre 2026). L'étape devient uses: artilleryio/action-cli@v2 avec command: run --target ${{ vars.STAGING_URL }} tests/load/api.yml --output report.json, et le plugin ensure fait sortir Artillery avec un code non nul quand un objectif est manqué. La section config du script :

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500

Locust se termine avec le code 1 dès qu'une requête a échoué, et pour des règles de latence, vous fixez environment.process_exit_code dans un écouteur de l'événement quitting, comme le montre la même page (vérifié le 9 octobre 2026). Après actions/setup-python@v7 avec python-version: "3.13" :

      - run: pip install locust
      - run: >
          locust -f tests/load/locustfile.py --headless
          -u 20 -r 5 -t 2m -H "$BASE_URL"
          --csv results --html report.html

JMeter tourne sans interface grâce à -n, et les options de ligne de commande de son manuel ne prévoient aucun seuil de réussite ou d'échec (vérifié le 9 octobre 2026). Une courte étape peut lire le fichier de résultats, au format CSV avec une colonne success par défaut, et faire échouer le job elle-même :

      - uses: actions/setup-java@v6
        with:
          distribution: temurin
          java-version: "21"
      - name: Install JMeter 5.6.3
        env:
          JM_BASE: https://archive.apache.org/dist/jmeter/binaries
        run: curl -sSL "$JM_BASE/apache-jmeter-5.6.3.tgz" | tar -xzf -
      - name: Run the test plan
        run: >
          apache-jmeter-5.6.3/bin/jmeter -n -t tests/load/plan.jmx
          -l results.jtl -e -o report
      - name: Fail above 1% errors
        run: |
          python3 - <<'EOF'
          import csv, sys
          rows = list(csv.DictReader(open("results.jtl")))
          bad = sum(r["success"] != "true" for r in rows)
          print(f"{bad} of {len(rows)} samples failed")
          sys.exit(1 if not rows or bad > 0.01 * len(rows) else 0)
          EOF

Comment faire échouer le job quand le test manque un objectif ?

Inscrivez les objectifs dans le test sous forme de seuils et laissez le code de sortie faire le reste. GitHub marque une étape en échec quand sa commande se termine avec un code non nul, et le job échoue avec elle.

Commencez par un taux d'erreur strict et un percentile de latence généreux, puis resserrez la limite de latence une fois que vous savez de combien vos chiffres varient d'une exécution à l'autre. Le guide pas à pas du test de charge explique comment choisir ces objectifs.

Où ranger les résultats de chaque exécution ?

Envoyez-les comme artefact du workflow, avec if: always() pour qu'un test en échec garde quand même son rapport. Les artefacts sont conservés 90 jours par défaut, et retention-days raccourcit cette durée.

Le README d'upload-artifact documente les 90 jours par défaut (vérifié le 9 octobre 2026). Réglez if-no-files-found: error pour qu'un rapport manquant fasse nettement échouer l'étape.

Quelle charge un runner hébergé par GitHub peut-il générer ?

Assez pour un smoke test ou un petit contrôle de régression. Un runner Linux standard dispose de 4 CPU et 16 Go de RAM dans les dépôts publics, de 2 CPU et 8 Go dans les dépôts privés, et un job s'arrête au bout de 6 heures.

Ces chiffres viennent de la référence des runners et des limites d'Actions de GitHub (vérifié le 9 octobre 2026), qui ne donnent aucun chiffre de bande passante réseau.

Un job tourne sur une seule machine et forme donc un seul générateur de charge : si son CPU sature, les temps de réponse incluent le temps d'attente sur le runner lui-même. Chaque requête part aussi de cette machine, si bien que les limiteurs de débit qui comptent par adresse client voient un seul client très actif. GitHub déconseille de mettre en liste d'autorisation les plages d'adresses IP Azure de ses runners Ubuntu ; les runners plus puissants (larger runners) des offres Team et Enterprise Cloud ajoutent du CPU, de la mémoire et des adresses IP statiques.

Quand la charge doit-elle venir d'ailleurs ?

Quand il vous faut plus de charge qu'une machine n'en produit, du trafic depuis plusieurs régions ou des exécutions plus longues que la limite d'un job.

Avec k6, run-k6-action exécute le test sur Grafana Cloud k6 si vous réglez cloud-run-locally: false et fournissez K6_CLOUD_TOKEN, K6_CLOUD_PROJECT_ID et, avec k6 v2, K6_CLOUD_STACK_ID. Une exécution cloud ignore par défaut l'environnement du runner : ajoutez donc -e BASE_URL=${{ vars.STAGING_URL }} à flags (vérifié le 10 octobre 2026). L'action d'Artillery peut appeler run-fargate ou run-lambda pour générer la charge depuis votre propre compte AWS (les deux vérifiés le 9 octobre 2026). La comparaison k6 vs Artillery couvre les deux.

Pour JMeter, LoadFocus documente une intégration avec GitHub Actions fondée sur son client npm. Vous enregistrez le test dans votre compte LoadFocus, stockez la clé d'API et l'ID d'équipe comme secrets, puis appelez run-test. Les options ci-dessous suivent l'aide du client :

      - run: npm install -g @loadfocus/loadfocus-api-client
      - env:
          LF_KEY: ${{ secrets.LOADFOCUS_API_KEY }}
          LF_TEAM: ${{ secrets.LOADFOCUS_TEAM_ID }}
        run: |
          test -n "$LF_KEY"
          test -n "$LF_TEAM"
          loadfocus-api config set \
            --apikey "$LF_KEY" --teamid "$LF_TEAM"
          loadfocus-api jmeter run-test --name checkout-api \
            --thresholds "avgresponse<=200,errors==0,p95<=250"

Le client attend jusqu'à 1 800 secondes par défaut (--wait-timeout change cette durée) : donnez donc au job un timeout-minutes supérieur à 30, par exemple 40. Il se termine avec le code 1 quand un seuil n'est pas tenu et avec le code 0 quand la clé d'API ou l'ID d'équipe manque, d'où les lignes test -n, qui font échouer l'étape dès qu'un secret est vide. La charge vient de LoadFocus, qui exécute des scripts JMeter depuis 25 régions cloud.

FAQ

Combien de temps doit durer un test de charge dans une pull request ? Quelques minutes : assez pour dépasser la montée en charge et obtenir un percentile stable, assez peu pour que personne ne l'attende.

A-t-on le droit de lancer des tests de charge depuis les runners hébergés par GitHub ? Les conditions de GitHub pour Actions interdisent de perturber un service et réservent les runners hébergés au travail sur le projet du dépôt (vérifié le 9 octobre 2026). Tester la préproduction de ce même projet, sans surcharger les serveurs de GitHub, correspond au type de test que décrivent ces conditions.

Puis-je utiliser un runner auto-hébergé à la place ? Oui. Il tourne sur votre propre matériel et votre propre réseau, et la page des limites de GitHub autorise un job jusqu'à 5 jours sur ce type de runner. Il reste un seul générateur de charge.

Test de charge Locust : l'outil Python passé en revue

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Locust est un outil de test de charge Python, gratuit et sous licence MIT, dans lequel chaque test est un programme Python, exécuté par des utilisateurs légers depuis une interface web ou la ligne de commande. Le test de charge Locust convient aux équipes qui écrivent du Python et testent surtout des services HTTP. Celles qui ont besoin de nombreux protocoles prêts à l'emploi ou d'un éditeur de tests graphique seront mieux servies par JMeter, et celles qui écrivent du JavaScript par k6.

Nous n'avons pas exécuté Locust pour cette revue. Les faits proviennent de la documentation, du dépôt et de la page PyPI de Locust, vérifiés le 9 octobre 2026, et les appréciations sont les nôtres.

Sujet	Locust
Licence	MIT
Environnement	Python 3.11 ou plus récent
Version actuelle	2.46.7 (4 octobre 2026)
Format des tests	Classes Python dans un locustfile
Exécution	Interface web sur le port 8089, ou headless
Protocoles intégrés	HTTP et HTTPS
Répartition	Un master et autant de workers que nécessaire
Résultats	Graphiques en direct, CSV, HTML, JSON, OpenTelemetry
CI	Code de sortie 1 dès qu'une requête échoue

Qui développe Locust, et le projet est-il toujours maintenu ?

Lars Holmberg maintient Locust, et Microsoft sponsorise ce travail. Les versions se succèdent vite : 17 depuis le début de 2026.

Le README de Locust cite les deux. PyPI indique la 2.46.7, publiée le 4 octobre 2026, comme dernière version, avec Python 3.11 ou plus récent requis (vérifié le 9 octobre 2026).

Comment fonctionne un locustfile ?

Un locustfile est un module Python ordinaire qui contient au moins une classe d'utilisateur. Chaque utilisateur simulé exécute ses tâches l'une après l'autre et marque une pause entre deux, selon son wait_time.

D'après le guide du locustfile, HttpUser donne à chaque utilisateur un client qui encapsule python-requests, conserve les cookies et enregistre chaque requête. Les méthodes marquées @task sont tirées au hasard, pondérées par le nombre passé au décorateur, et on_start s'exécute une fois par utilisateur. Cet utilisateur se connecte, parcourt le catalogue quatre fois plus souvent qu'il ne passe commande, et lance au plus une tâche toutes les 10 secondes :

from locust import HttpUser, task, constant_pacing


class Shopper(HttpUser):
    wait_time = constant_pacing(10)

    def on_start(self):
        self.client.post("/login", json={"user": "demo"})

    @task(4)
    def browse(self):
        self.client.get("/products?page=2", name="/products")

    @task
    def checkout(self):
        with self.client.post(
            "/checkout", catch_response=True
        ) as resp:
            if "order_id" not in resp.text:
                resp.failure("no order id")

catch_response permet de faire échouer une requête d'après son contenu, et name regroupe les URL variables sur une seule ligne des statistiques. Les autres fonctions d'attente sont constant, between, constant_throughput et, depuis la version 2.46.6, poisson ; notre guide sur le temps de réflexion en test de charge explique comment ces pauses façonnent la charge. La documentation précise que le temps d'attente peut seulement limiter le débit et ne lance pas de nouveaux utilisateurs pour atteindre un rythme cible. Un test Locust est donc un groupe fixe d'utilisateurs : un modèle de charge fermé.

Faut-il utiliser l'interface web ou le mode headless ?

L'interface web pour explorer, le mode headless pour des exécutions reproductibles.

La commande locust lance une interface web sur le port 8089. Vous y indiquez l'hôte, le nombre d'utilisateurs et la montée en charge, suivez des graphiques en direct et modifiez la charge en cours de test. Le mode headless reprend les mêmes réglages sous forme d'options :

locust -f locustfile.py --headless -u 200 -r 10 -t 10m \
  --host https://staging.example.com \
  --csv results --html report.html

-u fixe le nombre d'utilisateurs, -r le nombre d'utilisateurs démarrés par seconde et -t la durée, montée en charge comprise. Les mêmes réglages peuvent aussi être définis dans locust.conf ou pyproject.toml.

Comment fonctionne le mode distribué ?

Un processus master gère l'interface web et coordonne, tandis que des processus workers exécutent les utilisateurs et lui renvoient leurs statistiques. Il faut un worker par cœur de CPU, car un processus Python ne peut pas exploiter pleinement plus d'un cœur.

D'après la documentation sur la charge distribuée, un seul processus dépasse mille requêtes par seconde sur un plan de test simple ; pour aller plus loin, on répartit la charge :

# sur la machine master
locust -f locustfile.py --master
# sur chaque machine worker, un worker par cœur
locust -f - --worker --master-host 10.0.0.5 --processes -1

-f - récupère le locustfile auprès du master. --processes repose sur fork() et ne fonctionne donc pas sous Windows, et toute modification du locustfile impose de redémarrer tous les processus. La documentation décrit aussi un opérateur Kubernetes et Azure Load Testing (vérifié le 9 octobre 2026).

LoadFocus, l'éditeur de ce site, n'exécute pas de tests Locust. Il exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud ; pour Locust, les voies ci-dessus restent donc les moyens de monter en charge.

Locust peut-il tester d'autres protocoles que HTTP ?

Oui, à condition d'apporter un client Python pour le protocole. Seuls HTTP et HTTPS sont intégrés.

La page consacrée aux autres protocoles montre comment encapsuler un client pour que chaque appel soit enregistré, avec des exemples pour XML-RPC et gRPC et des classes d'utilisateur expérimentales pour MQTT, Socket.IO et OpenAI. Le projet distinct locust-plugins ajoute des utilisateurs pour Kafka, FTP, Selenium et Playwright (vérifié le 9 octobre 2026).

Pour HTTP, il existe aussi FastHttpUser, qui s'appuie sur geventhttpclient et consomme beaucoup moins de CPU. Dans le meilleur des cas, selon la documentation, un processus atteint environ 16 000 requêtes par seconde, contre 4 000 avec HttpUser. FastHttpUser ne rend pas chaque requête plus rapide, et il ne vérifie pas les certificats TLS par défaut.

Quels rapports Locust fournit-il, et comment s'intègre-t-il à la CI ?

Vous obtenez des graphiques en direct dans l'interface web et, à la demande, des fichiers de résultats. En CI, Locust se termine avec le code 1 si une requête a échoué.

D'après la référence de configuration, --csv écrit des fichiers de statistiques, d'historique et d'échecs, --html enregistre un rapport et --json affiche les statistiques finales. --otel exporte vers un backend OpenTelemetry. La documentation du mode headless montre un listener qui fait échouer l'exécution selon le taux d'échec, le temps de réponse moyen ou le 95e percentile, et notre guide du test de charge dans GitHub Actions l'intègre à un workflow.

Quels sont les points forts de Locust, et où sont ses limites ?

Locust brille par sa logique de test et avec de nombreux utilisateurs simultanés qui attendent la plupart du temps. Il est plus faible sur le nombre de requêtes par processus et sur les protocoles qu'il faut brancher soi-même.

Comme les tests sont du Python pur, boucles, conditions, données générées et votre propre client d'API fonctionnent tous, et les tests vivent dans le contrôle de version. La page What is Locust explique que le faible coût de chaque utilisateur convient aux charges très concurrentes, tout en admettant que d'autres outils peuvent envoyer plus de requêtes par seconde sur le même matériel.

Les limites que la documentation reconnaît elle-même :

Un processus Python n'utilise qu'un seul cœur de CPU.
Les bibliothèques qui font leurs E/S en C bloquent le processus, sauf si gevent peut les patcher.
HttpUser n'analyse pas le HTML et ne charge pas les ressources des pages.
Le temps d'attente ne peut pas ajouter d'utilisateurs pour tenir un débit de requêtes.

Quels autres outils Python existent pour les tests de charge ?

Locust est le moteur Python activement développé. Molotov, la principale alternative, n'a publié aucune version sur PyPI depuis 2022, et Taurus exécute Locust via l'un de ses exécuteurs.

Molotov est un outil pour Python 3.8+ construit sur asyncio et aiohttp ; sa dernière version sur PyPI est la 2.6, du 21 octobre 2022, et le dernier commit de sa branche principale date de novembre 2023 (vérifié le 21 octobre 2026). Taurus exécute un locustfile, ou de simples requêtes GET et POST écrites en YAML, via son exécuteur locust. Vous installez Locust vous-même, en mode distribué Taurus ne lance que le master, et son réglage throughput n'a aucun effet avec cet exécuteur (vérifié le 21 octobre 2026).

Quand choisir plutôt k6, JMeter ou Gatling ?

Choisissez un autre outil quand son langage, ses protocoles ou son modèle de charge conviennent mieux à votre équipe.

Notre panorama des outils de test de charge open source place Locust à côté de cinq autres.

Choisissez plutôt k6 si votre équipe écrit du JavaScript, veut des critères de réussite sous forme de thresholds dans le script, ou a besoin d'un modèle de charge ouvert, que fournissent les exécuteurs arrival-rate de k6 (vérifié le 9 octobre 2026). LoadFocus exécute des scripts k6 depuis 25 régions cloud, mais lance les scénarios arrival-rate avec un nombre fixe d'utilisateurs : pour tenir un débit de requêtes, exécutez-les avec k6 lui-même.

Choisissez plutôt JMeter si vous avez besoin de JDBC, JMS, LDAP ou FTP prêts à l'emploi, comme le liste son README, ou si vos testeurs construisent leurs tests dans une interface graphique. Locust vs JMeter compare les deux en détail.

Choisissez plutôt Gatling si votre équipe travaille sur la JVM et veut des profils d'injection ouverts et fermés dans une même API (vérifié le 9 octobre 2026). Gatling vs JMeter le présente plus en détail.

FAQ

Locust est-il gratuit pour un usage commercial ? Oui. Locust est publié sous licence MIT, qui autorise l'usage commercial, la modification et la redistribution.

Quelle version de Python faut-il pour Locust ? Python 3.11 ou plus récent, d'après ses métadonnées PyPI. Installez-le avec pip install locust, ou lancez-le dans un environnement temporaire avec uvx locust.

LoadFocus peut-il exécuter des tests Locust ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour monter un test Locust en charge, utilisez son mode master et workers, l'opérateur Kubernetes ou Azure Load Testing.

Locust vs JMeter : scripts Python ou plans de test JMeter ?

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Locust et Apache JMeter sont deux outils de test de charge gratuits et open source, et le bon choix dépend surtout de la façon dont votre équipe veut construire ses tests. Choisissez Locust si votre équipe écrit du Python et veut une logique de test sous forme de code ordinaire, exécutée par des utilisateurs légers et événementiels. Choisissez JMeter si vous avez besoin de protocoles au-delà de HTTP comme JDBC, JMS ou LDAP, si vous préférez construire vos tests dans une interface graphique, ou si vous avez déjà une bibliothèque de plans de test .jmx.

Les informations de ce comparatif Locust vs JMeter viennent de la documentation et du dépôt de chaque projet, vérifiées le 9 octobre 2026.

	Locust	Apache JMeter
Licence	MIT (dépôt)	Apache 2.0 (dépôt)
Environnement d'exécution	Python 3.11 ou plus récent	Java 8 ou plus récent (version 5.6.3)
Tests écrits en	Code Python dans un locustfile	Plans de test construits dans une interface graphique, enregistrés en XML (`.jmx`)
Interface graphique	Interface web pour lancer, ajuster et suivre un test en cours	IDE de bureau pour enregistrer, construire et déboguer des plans de test
Protocoles intégrés	HTTP et HTTPS ; les autres via un client Python	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, mail, TCP, commandes shell, objets Java
Utilisateurs virtuels	Un greenlet par utilisateur sur gevent (événementiel)	Un thread Java par utilisateur
Mode distribué	Un master et autant de workers que nécessaire	Un client qui pilote des serveurs JMeter distants
CI et exécution sans interface	`--headless`, code de sortie 1 si des requêtes échouent	Mode CLI (`jmeter -n`)
Rapports	Graphiques en direct dans l'interface web, fichiers CSV, rapport HTML	Tableau de bord HTML, résultats en direct via un Backend Listener

Quelle est la différence entre Locust et JMeter ?

Dans Locust, un test est un programme Python. Dans JMeter, un test est un plan que vous assemblez dans une interface graphique de bureau puis enregistrez dans un fichier, et la plupart des autres différences en découlent.

Le README de Locust décrit des tests écrits avec des boucles, des conditions et des bibliothèques Python ordinaires. Locust s'installe avec pip install locust et demande Python 3.11 ou plus récent, d'après ses métadonnées de paquet.

Un test JMeter est un arbre d'éléments : un Thread Group pour les utilisateurs, des samplers pour les requêtes, des assertions et des listeners pour les résultats. JMeter 5.6.3, la version actuelle sur la page de téléchargement, demande Java 8 ou plus récent. Le README de la branche de développement de JMeter exige déjà Java 17 (vérifié le 10 octobre 2026). Quand une étape a besoin d'une vraie logique, un sampler JSR223 exécute un script Groovy à l'intérieur du plan.

Comment écrit-on un test avec chaque outil ?

Dans Locust, vous écrivez une classe Python pour chaque type d'utilisateur, avec des méthodes marquées comme tâches. Dans JMeter, vous ajoutez un Thread Group et des samplers dans l'interface graphique, vous enregistrez le plan puis vous le lancez en ligne de commande.

Un utilisateur Locust qui attend une à trois secondes entre deux tâches et consulte la liste des utilisateurs trois fois plus souvent qu'une fiche individuelle :

from locust import HttpUser, task, between


class ApiUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def list_users(self):
        self.client.get("/api/users")

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Lancement sans interface avec 50 utilisateurs, cinq nouveaux par seconde, pendant cinq minutes :

locust -f locustfile.py --headless -u 50 -r 5 \
  --run-time 5m --host https://staging.example.com

Dans JMeter, le même test est un Thread Group de 50 threads avec une durée de montée en charge, qui contient deux samplers HTTP Request. Le guide de démarrage lance un plan enregistré en mode CLI, et -e -o ajoute le rapport HTML à la fin :

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Le fichier .jmx est du XML, comme le montrent les exemples livrés avec JMeter, et il se relit moins facilement en pull request que du Python. JMeter sait aussi enregistrer un plan depuis un navigateur ; l'équivalent côté Locust est har2locust, un convertisseur d'enregistrements HAR en locustfile encore en bêta (vérifié le 9 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

JMeter couvre beaucoup plus de protocoles d'origine. Locust fournit HTTP et HTTPS et vous laisse apporter un client Python pour tout le reste.

Le README de JMeter cite HTTP et HTTPS, SOAP et REST, FTP, les bases de données via JDBC, LDAP, la messagerie JMS, le mail en SMTP, POP3 et IMAP, TCP, les commandes natives et les objets Java. JDBC et JMS demandent les fichiers JAR du pilote, fournis par l'éditeur de votre base de données ou de votre solution JMS.

La page sur les autres protocoles de la documentation Locust montre comment encapsuler une bibliothèque de protocole, avec des exemples pour gRPC, XML-RPC et MQTT, et renvoie à locust-plugins pour Kafka, Selenium et Playwright (vérifié le 9 octobre 2026). La bibliothèque doit être compatible avec gevent, car des entrées-sorties faites en code C compilé bloquent tout le processus ; la documentation cite le pilote PostgreSQL psycopg2, qui a besoin d'un paquet supplémentaire. Pour tester une base de données sous charge, le sampler JDBC de JMeter est le chemin le plus court.

Comment fonctionnent les utilisateurs virtuels dans Locust et JMeter ?

JMeter exécute chaque utilisateur virtuel dans un thread Java. Locust exécute chaque utilisateur dans un greenlet sur la boucle d'événements de gevent, ce qui réduit le coût de chaque utilisateur.

Chaque thread d'un Thread Group JMeter exécute tout le plan de façon indépendante. JMeter démarre par défaut avec un tas (heap) de 1 Go, ce qui, selon son guide, peut ne pas suffire pour des plans plus lourds et de nombreux threads.

D'après son README, un seul processus Locust peut gérer plusieurs milliers d'utilisateurs simultanés. La documentation sur la charge distribuée précise qu'un processus Python ne peut pas exploiter pleinement plus d'un cœur de processeur : on lance donc un worker par cœur, ce que --processes fait pour vous sur une seule machine.

Comment répartir un test sur plusieurs machines ?

Les deux outils ont un mode distribué intégré. Dans Locust, un master pilote des workers qui exécutent les utilisateurs, et dans JMeter, le client lance le plan de test complet sur chaque serveur distant.

Dans Locust, un processus lancé avec --master fait tourner l'interface web et indique aux processus --worker quand démarrer et arrêter des utilisateurs. La documentation de Locust présente aussi un opérateur Kubernetes et Azure Load Testing, un service Microsoft qui exécute des tests Locust dans le cloud (vérifié le 9 octobre 2026).

Le mode de test distant de JMeter permet à un client de piloter autant de serveurs que nécessaire via RMI. Chaque serveur exécute tout le plan : 1 000 threads sur six serveurs donnent donc 6 000 threads. Tous les nœuds devraient utiliser la même version de JMeter et de Java, RMI a besoin d'un keystore sauf si SSL est désactivé, et les fichiers de données doivent être copiés sur chaque serveur.

Il existe une troisième voie pour les plans de test JMeter. LoadFocus, l'éditeur de ce site, exécute vos plans de test JMeter existants sans modification depuis 25 régions cloud, sans serveurs distants à configurer. LoadFocus n'exécute pas les tests Locust : pour Locust, les options ci-dessus restent les moyens de monter en charge.

Comment s'intègrent-ils à la CI, et quels rapports obtient-on ?

Les deux s'exécutent sans interface, en ligne de commande. Locust se termine en plus avec le code de sortie 1 quand des requêtes échouent, et JMeter produit le rapport HTML le plus complet.

La documentation du mode headless de Locust montre un court écouteur d'événement qui fixe le code de sortie selon le taux d'échec, le temps de réponse moyen ou le 95e percentile, ainsi qu'un exemple pour GitHub Actions. Les options --csv et --html enregistrent les résultats et un rapport après l'exécution.

La documentation de JMeter est claire : les tests de charge se lancent en mode CLI, et l'interface graphique sert à construire et à déboguer. Son README renvoie à des bibliothèques tierces pour Maven, Gradle et Jenkins. Le tableau de bord JMeter comprend une table APDEX, un tableau de statistiques avec trois percentiles configurables, des synthèses d'erreurs et des graphiques de temps de réponse.

Quel outil choisir ?

Choisissez Locust si votre équipe écrit du Python et veut relire ses tests de charge comme le reste de son code. Choisissez plutôt JMeter si vous avez besoin de protocoles au-delà de HTTP, si vos testeurs préfèrent une interface graphique ou si vous avez déjà des plans .jmx.

Locust convient aux scénarios avec des boucles, des branchements et des données générées, aux tests qui réutilisent un client Python interne pour votre API, et à une forte concurrence d'utilisateurs qui passent la plupart de leur temps à attendre.

JMeter est le meilleur choix pour tester JDBC, JMS, LDAP, FTP ou le mail, là où Locust demanderait un client à maintenir vous-même, ainsi que pour les testeurs qui enregistrent un parcours dans le navigateur et l'affinent visuellement. Une entreprise qui utilise déjà JMeter conserve en outre ses plans et son savoir-faire.

FAQ

Locust est-il plus rapide que JMeter ? Nous ne l'avons pas mesuré nous-mêmes, donc nous ne désignerons pas de gagnant. La comparaison honnête consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Locust peut-il exécuter des fichiers .jmx de JMeter ? Pas d'après sa documentation, qui décrit les tests uniquement comme des locustfiles Python. Passer un plan de test JMeter à Locust revient à le réécrire en Python.

LoadFocus peut-il exécuter des tests Locust ? Non. LoadFocus exécute des scripts JMeter et k6. Pour étendre un test Locust au-delà d'une machine, utilisez le mode master et workers de Locust, son opérateur Kubernetes ou Azure Load Testing.

Modèle de charge ouvert ou fermé : lequel choisir ?

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Choisir un modèle de charge ouvert ou fermé dépend surtout de la façon dont les utilisateurs atteignent votre système. Prenez le modèle ouvert, qui démarre de nouvelles itérations à un taux d'arrivée fixé, pour les sites et API publics où les utilisateurs continuent d'arriver même quand vous ralentissez, et le modèle fermé, un nombre fixe d'utilisateurs virtuels qui attendent chacun la fin de leur itération précédente, seulement là où le système plafonne lui-même la concurrence. Le choix pèse surtout en saturation, quand un test fermé freine sa propre charge et fait paraître le système plus sain qu'il ne l'est.

Les faits sur les outils viennent de la documentation de chaque projet, vérifiée le 9 octobre 2026.

	Modèle ouvert	Modèle fermé
Vous fixez	Nouvelles itérations ou nouveaux utilisateurs par seconde	Utilisateurs virtuels simultanés
Quand les réponses ralentissent	Le travail continue d'arriver, les files d'attente grossissent	Les utilisateurs attendent, la charge envoyée baisse
Systèmes réels de ce type	La plupart des sites et API publics	Centres d'appels, files de billetterie, pools de workers
k6	`constant-arrival-rate`, `ramping-arrival-rate`	`constant-vus`, `ramping-vus`
Gatling	`injectOpen`	`injectClosed`
Locust	Approché avec `constant_throughput` ou `poisson`	Utilisateurs avec un `wait_time`
JMeter	Open Model Thread Group, plugin Arrivals	Thread Group

Quelle est la différence entre un modèle de charge ouvert et un modèle fermé ?

Dans un modèle ouvert, c'est le générateur de charge qui décide quand le travail arrive, et dans un modèle fermé, c'est le temps de réponse du système.

La documentation de k6 le dit clairement : dans le modèle fermé, l'itération suivante d'un utilisateur virtuel ne démarre qu'une fois la précédente terminée, alors que dans le modèle ouvert les nouvelles itérations arrivent indépendamment de la fin des précédentes (vérifié le 9 octobre 2026). Un test fermé avec 50 utilisateurs virtuels n'a jamais plus de 50 itérations en cours. Un test ouvert à 50 itérations par seconde en lance 50 de plus chaque seconde, et si chacune dure plus longtemps, davantage se chevauchent.

Pourquoi un modèle fermé masque-t-il la latence quand le système sature ?

Parce que le test ralentit en même temps que le système. Quand les réponses prennent plus de temps, chaque utilisateur d'un modèle fermé envoie moins de requêtes, et la charge baisse au moment précis où vous vouliez la voir monter.

La documentation de k6 décrit l'effet : des réponses plus lentes allongent les itérations et réduisent le taux d'arrivée des nouvelles. La page de Gatling sur les modèles de charge va plus loin et qualifie de test cassé, qui vérifie un comportement imaginaire, un modèle fermé appliqué à un système en réalité ouvert (vérifié le 9 octobre 2026).

Un test fermé montre donc des temps de réponse qui plafonnent, car il ne peut jamais y avoir plus de requêtes en cours que d'utilisateurs. Un test ouvert montre la file qui grossit, avec des temps de réponse qui montent tant que les arrivées dépassent ce que le système traite. C'est cette seconde image que vos utilisateurs verraient, et les temps de réponse p95 et p99 que vous lisez à la fin ne valent que ce que vaut le modèle de charge qui les a produits.

La documentation de k6 note qu'une partie de la littérature sur les tests appelle ce problème coordinated omission. Un article USENIX de 2006 cité par la documentation de Gatling, Open Versus Closed: A Cautionary Tale, conclut que les deux modèles donnent des résultats nettement différents, même avec la même charge et les mêmes demandes de service.

Quel modèle correspond à votre trafic réel ?

Prenez un modèle ouvert pour tout ce que le public peut atteindre, et un modèle fermé seulement là où le système limite lui-même le nombre d'utilisateurs actifs en même temps.

La documentation de Gatling cite comme systèmes fermés les centres d'appels où tous les opérateurs sont occupés et les sites de billetterie qui placent les utilisateurs dans une file d'attente à pleine capacité, et indique que la plupart des sites web se comportent comme des systèmes ouverts. Un traitement par lots avec un nombre fixe de workers, ou un consommateur de file à concurrence fixée, est fermé lui aussi. Les API publiques, les pages web et les webhooks sont ouverts : rien ne retient la requête suivante parce que la précédente a été lente.

Beaucoup de systèmes se situent entre les deux : une cliente arrive à son propre rythme, puis attend chaque page pendant sa visite. L'article cité plus haut parle de modèle partiellement ouvert. Dans k6 ou Gatling, fixez le taux d'arrivée des sessions et faites de chaque itération un parcours utilisateur complet, avec ses propres pauses.

Comment régler chaque modèle dans k6 ?

Par l'executor. constant-vus et ramping-vus donnent un modèle fermé, constant-arrival-rate et ramping-arrival-rate un modèle ouvert.

Un scénario fermé définit executor: "constant-vus" avec un nombre de vus et une duration. Un scénario ouvert fixe plutôt un taux, et vous préallouez assez d'utilisateurs virtuels pour le tenir :

export const options = {
  scenarios: {
    open_model: {
      executor: "constant-arrival-rate",
      rate: 50,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 100,
    },
  },
  thresholds: {
    dropped_iterations: ["count<10"],
  },
};

k6 ne démarre une itération que s'il dispose d'un utilisateur virtuel libre, et sa documentation déconseille de compter sur maxVUs, car ajouter des utilisateurs en cours de test peut surcharger le générateur de charge. Quand aucun utilisateur n'est libre, k6 enregistre une itération abandonnée, ce qui, tard dans un test, signifie souvent que le système ralentit. Le seuil ci-dessus fait échouer l'exécution à partir de dix. Ne mettez pas de sleep() à la fin d'une itération à taux d'arrivée, puisque l'executor cadence déjà les démarrages (vérifié le 9 octobre 2026).

Si vous exécutez des scripts k6 sur LoadFocus, son exécution k6 dans le cloud prend la charge dans les réglages du test, et son validateur de script prévient que les scénarios à taux d'arrivée y tournent avec un nombre fixe d'utilisateurs, si bien que le débit de requêtes n'est pas maintenu. Pour un vrai test en modèle ouvert, lancez les executors à taux d'arrivée avec k6 lui-même, ou sur un service qui les exécute tels qu'ils sont écrits.

Comment Gatling, Locust et JMeter expriment-ils chaque modèle ?

Gatling sépare les deux modèles dans son API, JMeter propose les deux à travers des thread groups différents, et Locust est construit autour d'un nombre fixe d'utilisateurs.

Gatling. Un scénario utilise soit injectOpen, soit injectClosed. Les étapes ouvertes comme constantUsersPerSec et rampUsersPerSec fixent des taux d'arrivée, les étapes fermées comme constantConcurrentUsers et rampConcurrentUsers fixent la concurrence. Un même profil d'injection ne peut pas mélanger les deux (vérifié le 9 octobre 2026).

Locust. Vous fixez un nombre d'utilisateurs, et le wait_time de chaque utilisateur règle la pause entre les tâches. constant_throughput et constant_pacing ajustent cette pause pour que chaque utilisateur exécute au plus un nombre donné de tâches par seconde, mais la documentation précise que le temps d'attente ne peut que limiter le débit et ne lance pas de nouveaux utilisateurs pour atteindre une cible. poisson() tire des pauses aléatoires, que la documentation juge plus proches des arrivées réelles. L'exemple de la documentation pour 500 itérations de tâche par seconde est constant_throughput(0.1) avec 5 000 utilisateurs, un pool fermé avec beaucoup de marge (vérifié le 9 octobre 2026).

JMeter. Le Thread Group classique est un pool fermé de threads. Les timers Constant Throughput et Precise Throughput cadencent ce pool vers un taux cible, et la référence prévient que le débit baisse si le serveur ne suit pas ou s'il n'y a pas assez de threads. Pour les arrivées, JMeter 5.5 a ajouté l'Open Model Thread Group, toujours marqué comme expérimental, avec des plannings comme rate(10/sec) random_arrivals(1 min). Le plugin communautaire Arrivals Thread Group démarre de nouveaux threads quand tous les threads existants sont occupés, avec une limite de concurrence comme soupape de sécurité (vérifié le 9 octobre 2026).

Que surveiller pendant un test en modèle ouvert ?

Surveillez le générateur de charge d'aussi près que le système testé. En modèle ouvert, un système lent signifie plus d'utilisateurs simultanés de votre côté, et ils coûtent de la mémoire et du CPU.

Fixez un plafond, par exemple maxVUs dans k6 ou la limite de concurrence du plugin JMeter, et considérez le fait de l'atteindre comme un résultat : le système n'a pas pu absorber le taux demandé.

FAQ

Un modèle de charge fermé est-il parfois le bon choix ? Oui. Utilisez-le quand le système réel plafonne la concurrence, par exemple avec un pool fixe de workers, un consommateur de file ou un centre d'appels, ou quand vous voulez savoir combien de sessions simultanées un composant supporte. Pour le trafic web public, un modèle ouvert convient mieux.

Ajouter du temps de réflexion transforme-t-il un modèle fermé en modèle ouvert ? Non. Le temps de réflexion réduit la fréquence des requêtes de chaque utilisateur, mais chaque utilisateur attend toujours la réponse précédente, donc un système lent freine quand même le test. Seul un taux d'arrivée fixé indépendamment des temps de réponse donne un modèle ouvert.

Combien d'utilisateurs virtuels faut-il pour un test à taux d'arrivée ? Assez pour couvrir toutes les itérations en cours au même moment. La documentation de k6 suggère la durée médiane d'une itération multipliée par le taux cible, plus une marge pour la variabilité, à trouver par de courts essais avant le test complet.

Temps de réflexion en test de charge : bien le régler

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Le temps de réflexion en test de charge est la pause qu'un utilisateur virtuel marque entre deux actions, qui représente les secondes qu'une vraie personne passe à lire une page ou à remplir un formulaire. Il fixe la pression qu'exerce chaque utilisateur virtuel : plus la pause est longue, moins le même nombre d'utilisateurs envoie de requêtes par seconde. Mesurez-le à partir des données de vrais utilisateurs, faites-le varier au hasard autour de cette valeur et écrivez-le dans le script avec la commande de pause de votre outil.

Temps de réflexion par boucle	Une boucle dure	Requêtes par seconde pour 100 utilisateurs
0 s	0,5 s	200
1 s	1,5 s	environ 67
3 s	3,5 s	environ 29
5 s	5,5 s	environ 18
10 s	10,5 s	environ 10

Ce n'est qu'un calcul, sans test derrière : une requête par boucle, une réponse en 0,5 seconde, et le nombre d'utilisateurs divisé par (temps de réponse + temps de réflexion).

Qu'est-ce que le temps de réflexion en test de charge ?

Le temps de réflexion est l'attente volontaire qu'un script de test insère entre les étapes d'un parcours utilisateur. Il reproduit la part humaine d'une session : lire, comparer, taper.

Dans le script d'une boutique, il se place entre « ouvrir la fiche produit » et « ajouter au panier », en dehors de toute requête. Le guide de LoadFocus sur les délais en test de charge le distingue du délai de montée en charge, qui ajoute les utilisateurs progressivement, et du délai de démarrage entre deux utilisateurs, et note que beaucoup d'outils désignent par le simple mot « delay » le délai de montée en charge. Quand un outil propose un champ « delay », vérifiez lequel des trois il désigne.

Pourquoi le temps de réflexion change-t-il la charge à nombre d'utilisateurs égal ?

Avec un nombre fixe d'utilisateurs virtuels, chacun attend une réponse, fait une pause, et seulement ensuite envoie la requête suivante. Sa boucle dure le temps de réponse plus le temps de réflexion, donc chaque seconde de pause en plus réduit le nombre de requêtes que chaque utilisateur envoie par seconde.

Cent utilisateurs sans pause envoient 200 requêtes par seconde avec une réponse en 0,5 seconde ; avec une pause de 5 secondes, ils en envoient environ 18, si bien que deux tests « à 100 utilisateurs » peuvent être très différents. La documentation de k6 décrit le même effet pour son modèle fermé : l'itération suivante ne démarre que lorsque la précédente est terminée, donc des réponses plus lentes font aussi baisser le rythme (vérifié le 9 octobre 2026).

Réduire le temps de réflexion pour tirer plus de charge de moins d'utilisateurs a un coût : vingt utilisateurs sans pause peuvent atteindre la cadence de requêtes de plusieurs centaines d'utilisateurs qui marquent des pauses, tout en gardant bien moins de sessions et de connexions ouvertes que la production.

Quelle est la différence entre temps de réflexion et pacing ?

Le temps de réflexion est une pause après une étape, donc une boucle s'allonge dès que les réponses ralentissent. Le pacing fixe l'intervalle entre le début d'une boucle et le début de la suivante, et raccourcit l'attente quand le travail a pris plus de temps.

Avec un pacing de 30 secondes, un utilisateur lance une boucle toutes les 30 secondes, que ses requêtes aient pris 2 secondes ou 20, ce qui convient à un test construit à partir de volumes métier comme « 500 commandes par heure ». La documentation de constant_pacing dans Locust précise le cas limite : si la tâche dure plus longtemps que l'intervalle, l'attente tombe à zéro (vérifié le 9 octobre 2026). Beaucoup de scripts combinent les deux, avec du temps de réflexion entre les étapes et un pacing sur la boucle entière.

Le temps de réflexion doit-il être fixe ou aléatoire ?

Aléatoire, autour d'une moyenne mesurée. Une pause fixe maintient synchronisés les utilisateurs partis ensemble, qui arrivent sur la même page au même moment, boucle après boucle.

Ces vagues synchronisées peuvent créer des pics que la production ne connaît pas, et une pause aléatoire disperse les utilisateurs. Gardez la moyenne là où vos données la placent : une pause uniforme entre 2 et 8 secondes fait 5 en moyenne, soit la même charge moyenne qu'une pause fixe de 5 secondes. La loi uniforme est le choix simple par défaut ; une loi normale (gaussienne) regroupe les pauses autour d'une valeur typique, et une loi exponentielle donne beaucoup d'attentes courtes et quelques longues.

Comment choisir les valeurs du temps de réflexion ?

Tirez-les de ce que font les vrais utilisateurs à chaque étape, grâce à vos outils d'analyse web, vos logs d'accès ou un outil de suivi des utilisateurs réels (RUM). Prenez une valeur par étape, car lire une fiche produit prend plus de temps que cliquer sur un bouton.

Le temps passé sur la page dans vos outils d'analyse, ou l'écart entre deux requêtes successives d'une même session dans les logs d'accès, s'approche du temps de réflexion de cette étape. Prenez la médiane comme pause moyenne et la dispersion pour fixer la plage aléatoire, et écartez les temps morts comme un onglet resté ouvert pendant le déjeuner.

Une API appelée par d'autres programmes n'a pas d'humain dans la boucle : modélisez directement sa cadence de requêtes. Sans données, notez les valeurs supposées dans le plan de test pour qu'un test ultérieur les remplace ; le guide pas à pas du test de charge montre où elles s'insèrent.

Comment ajouter du temps de réflexion dans k6, JMeter, Gatling, Locust et Artillery ?

Chaque outil a sa propre commande de pause, et la plupart proposent aussi un pacing ou un réglage de débit.

Outil	Pause fixe	Pause aléatoire	Pacing ou débit
k6	`sleep(3)`	`sleep(2 + Math.random() * 6)`	Exécuteurs arrival-rate
JMeter	Constant Timer	Uniform ou Gaussian Random Timer	Constant Throughput Timer
Gatling	`pause(3)`	`pause(2, 8)`	`pace(30)`
Locust	`constant(3)`	`between(2, 8)`	`constant_pacing`
Artillery	`think: 3`	`think` + `jitter` (dans `config.http.defaults`)	Taux d'arrivée par phase

Les informations du tableau ci-dessus et des notes ci-dessous viennent de la documentation de chaque projet, vérifiées le 9 octobre 2026 ; les cinq outils figurent dans notre tour d'horizon des outils de test de charge open source.

k6. sleep(t) met l'utilisateur virtuel en pause pendant t secondes ; la documentation construit des pauses aléatoires avec Math.random() ou avec randomIntBetween() de k6-utils :

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // 2 à 8 secondes
  http.get("https://example.com/cart");
}

JMeter. Parmi les timers, le Constant Timer prend un délai en millisecondes, les Uniform et Gaussian Random Timers ajoutent une part aléatoire à un décalage fixe, et le Constant Throughput Timer fait varier ses pauses pour tenir un objectif d'échantillons par minute. Un timer s'exécute avant chaque sampler de sa portée, donc un seul timer au niveau du Thread Group fait une pause avant chaque requête.

Gatling. pause(2, 8) attend un temps aléatoire uniforme, et pace(30) dans une boucle l'exécute au plus une fois toutes les 30 secondes. Au niveau de la simulation, vous pouvez passer toutes les pauses à une loi normale ou exponentielle, ou les couper avec disablePauses().

Locust. wait_time s'applique après chaque tâche, donc une tâche de deux requêtes sous constant_throughput(2) envoie quatre requêtes par seconde et par utilisateur.

Artillery. Une étape think fait une pause d'un nombre de secondes donné, et un réglage think.jitter sous config.http.defaults ajoute une variation aléatoire à chaque étape think. Pour deux de ces outils face à face, voyez k6 vs Artillery.

Le temps de réflexion compte-t-il dans un test à taux d'arrivée ?

Moins, pour ce qui est de la cadence de requêtes. Quand l'outil lance de nouvelles itérations à un rythme fixé, les pauses déterminent combien de temps chaque utilisateur reste, et donc combien sont actifs en même temps.

Les exécuteurs arrival-rate de k6 cadencent les itérations par leur taux, et la documentation déconseille un sleep en fin d'itération ; les phases de charge d'Artillery créent de même un nombre fixe de nouveaux utilisateurs virtuels par seconde (vérifié le 9 octobre 2026 pour les deux). Le temps de réflexion entre les étapes façonne malgré tout chaque session.

Comment les outils de script de LoadFocus fixent-ils le temps de réflexion ?

Ils l'écrivent dans le script k6 ou JMeter comme valeur de départ, à ajuster ensuite.

L'import depuis cURL, HAR, Postman ou OpenAPI transforme une requête capturée en script k6 qui termine chaque itération par sleep(1) ; considérez cette seconde comme une valeur provisoire à remplacer par vos mesures. Le générateur de tests par IA de LoadFocus a pour consigne de donner un temps de réflexion à chaque étape, l'écrit sous forme de sleep() pour k6 ou de Constant Timer pour JMeter, et prévient quand un scénario à plusieurs étapes n'en a aucun.

FAQ

Peut-on lancer un test de charge sans temps de réflexion ? Oui, pour trouver le débit maximal d'un endpoint ou pour un test de stress, à condition de présenter le résultat en requêtes par seconde. Il en dit peu sur le nombre de vrais utilisateurs que le système peut servir.

Le temps de réflexion compte-t-il dans le temps de réponse ? Pas dans les temps des requêtes. Dans k6, http_req_duration couvre l'envoi, l'attente et la réception, tandis que iteration_duration couvre toute la boucle (référence des métriques, vérifié le 9 octobre 2026). Un Transaction Controller de JMeter exclut les timers de son temps, sauf si vous cochez l'option qui les inclut.

Outils de test de charge WebSocket : six options

Fri, 09 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Parmi les outils de test de charge WebSocket, k6, Artillery, Gatling et Tsung gèrent le protocole nativement, tandis que JMeter a besoin du plugin WebSocket Samplers et Locust de code client que vous écrivez ou de son utilisateur Socket.IO expérimental. Choisissez selon le langage de votre équipe, puis selon la rigueur avec laquelle vous devez vérifier les messages que le serveur renvoie.

Pour cet article, nous n'avons pas lancé ces outils contre un serveur WebSocket. Les informations viennent de la documentation et du dépôt de chaque projet, vérifiées le 9 octobre 2026, et les conseils « Choisissez plutôt » sont notre jugement.

Outil	Prise en charge de WebSocket	Tests écrits en	Vérifier ce que le serveur envoie
k6	Intégrée : `k6/websockets`, ancien `k6/ws`	JavaScript	Gestionnaires d'événements dans votre script
Artillery	Moteurs intégrés `ws` et `socketio`	YAML, plus des fonctions JavaScript	Réponses et accusés de réception Socket.IO
Gatling	Fait partie du SDK HTTP	Java, Kotlin, Scala, JavaScript	Checks qui attendent un message précis
Apache JMeter	Plugin WebSocket Samplers	Plans de test construits dans l'interface graphique	Samplers request-response et de lecture
Locust	Votre propre client, ou le `SocketIOUser` expérimental	Python	Ce que votre code remonte
Tsung	Type de session intégré `ts_websocket`	XML	`ack` attend une réponse du serveur

En quoi la charge WebSocket diffère-t-elle de la charge HTTP ?

Un utilisateur WebSocket ouvre une connexion et la garde pendant toute la session, et le serveur peut envoyer des messages quand il le veut. Un test a donc deux leviers, les connexions ouvertes et les messages par seconde, et chacun sollicite le serveur à sa façon.

Le guide WebSocket de k6 décrit un trafic full-duplex sur une seule connexion TCP et explique qu'un utilisateur virtuel y exécute une boucle d'événements tant que le socket reste ouvert, sans plus boucler sur la fonction principale. La référence WebSocket de Gatling ajoute que le trafic circule dans les deux sens, si bien que le modèle requête-réponse de HTTP ne convient plus.

Prévoyez trois formes de test. Beaucoup de connexions inactives montrent combien de sockets vos serveurs peuvent tenir. Un groupe plus restreint de clients bavards teste le traitement des messages. Une diffusion, où un message part vers tous les abonnés, teste le chemin du push.

Que faut-il mesurer dans un test de charge WebSocket ?

Mesurez le temps de connexion, la latence des messages et les connexions perdues, ainsi que le nombre de connexions qui restent ouvertes. Ce sont ces valeurs que ressentent les utilisateurs d'une application temps réel.

Les métriques intégrées de k6 comprennent ws_connecting, ws_ping, ws_session_duration, ws_sessions et des compteurs de messages. Aucune ne chronomètre un message applicatif : le délai entre le message d'un client et la réponse du serveur demande une métrique Trend personnalisée. Le moteur ws d'Artillery remonte le nombre et le débit des messages, et son moteur Socket.IO ajoute socketio.response_time, de l'émission d'un message à la réception de la réponse.

Pour les connexions perdues, comptez les événements close et error que votre script n'a pas provoqués, et comparez les sessions ouvertes à celles encore actives à la fin de chaque palier.

Quand k6 est-il le bon outil WebSocket ?

Quand votre équipe écrit du JavaScript et que chaque utilisateur virtuel doit tenir plusieurs sockets à la fois. k6 intègre WebSocket d'origine, sans extension à installer.

Le module k6/websockets suit l'API WebSocket du navigateur et utilise une boucle d'événements globale, qui permet à un utilisateur virtuel de garder plusieurs connexions ouvertes. L'ancien module k6/ws reste documenté, mais k6 recommande k6/websockets pour les nouveaux tests, et k6/experimental/websockets est déprécié.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Les thresholds fonctionnent aussi sur les métriques personnalisées : un objectif de latence manqué donne donc à la CI un code de sortie non nul. Choisissez plutôt Artillery quand votre serveur parle Socket.IO et que vous voulez vérifier émissions et accusés de réception sans écrire de code client. Notre comparatif k6 vs Artillery couvre les autres différences.

Quand Artillery a-t-il du sens ?

Quand vous voulez des scénarios YAML courts, ou quand votre serveur utilise Socket.IO. Les deux moteurs sont fournis avec Artillery.

Un scénario sur le moteur WebSocket se compose de cinq actions : connect, send, think, loop et function. Le moteur Socket.IO va plus loin : un emit peut déclarer la réponse attendue, valider un accusé de réception par une correspondance JSONPath et partager un scénario avec des requêtes HTTP, ce qui convient aux applications qui se connectent en HTTP avant d'ouvrir un socket.

Choisissez plutôt k6 ou Gatling quand un test doit vérifier ce qu'un serveur WebSocket brut renvoie, car la documentation du moteur ws ne décrit aucune étape qui attende ou compare une réponse.

À qui s'adresse Gatling pour les WebSockets ?

Aux équipes sur la JVM, ou sur le SDK JavaScript de Gatling, qui veulent écrire les vérifications de messages dans le scénario. La prise en charge de WebSocket fait partie du SDK HTTP de Gatling, si bien que les étapes HTTP et WebSocket partagent une même simulation.

La référence couvre connect, sendText, sendBytes et close, ainsi que des checks qui bloquent jusqu'à l'arrivée du message attendu ou l'expiration d'un délai. Les réglages du protocole permettent de reconnecter un socket fermé par le serveur, de répondre automatiquement à certains messages texte comme un ping et de garder en mémoire tampon les messages qu'aucun check n'a reconnus. Le dépôt range WebSocket dans la Community Edition sous Apache 2.0, sans limite.

Choisissez plutôt k6 si vous préférez traiter les messages poussés dans des gestionnaires d'événements que dans des checks bloquants.

JMeter peut-il tester la charge des WebSockets ?

Oui, avec un plugin. JMeter n'a pas de sampler WebSocket, et l'extension habituelle est WebSocket Samplers de Peter Doornbosch.

La référence des composants de JMeter ne mentionne jamais WebSocket. Le dépôt du plugin décrit six samplers : ouverture de connexion, request-response, ping-pong, lecture simple, écriture simple et fermeture. Ils tournent sur le thread du groupe de threads, gèrent wss et les trames binaires, et peuvent filtrer les trames sans intérêt pour le test. On l'installe via le Plugins Manager ou en copiant son jar dans lib/ext, et la version 1.3.2 a été taguée en janvier 2026 (vérifié le 9 octobre 2026).

Choisissez un autre outil si vous préférez ne pas maintenir un plugin tiers sur chaque générateur de charge.

Et Locust et Tsung ?

Locust n'atteint les WebSockets bruts que par du code client que vous ajoutez, et Tsung les prend en charge dans sa configuration XML mais publie rarement de nouvelles versions. Les deux fonctionnent, au prix de plus d'efforts.

Selon la documentation de Locust, l'outil ne gère d'origine que HTTP et HTTPS ; les autres protocoles s'ajoutent en enveloppant une bibliothèque cliente et en déclenchant un événement request après chaque appel. La bibliothèque doit pouvoir être patchée par gevent, sinon elle bloque tout le processus. Pour Socket.IO, il existe un SocketIOUser expérimental. Choisissez Locust si votre équipe écrit du Python et accepte de maintenir ce code client.

Tsung est un projet Erlang qui se présente comme un outil de test de charge distribué et multi-protocole. Sa documentation des sessions définit pour WebSocket les requêtes connect, message et close, avec un attribut ack pour attendre une réponse. Sa dernière version taguée, la 1.8.0, date de mars 2023.

Où se situe un service hébergé comme LoadFocus ?

Tenir beaucoup de sockets ouverts depuis vos propres machines demande du travail, et un service hébergé prend en charge la génération de charge. Il convient surtout quand vos tests sont déjà des scripts k6.

LoadFocus, l'éditeur de ce site, exécute des scripts k6 depuis 25 régions cloud, et sa page k6 cite les connexions WebSocket parmi les fonctionnalités k6 prises en charge. Il propose aussi un modèle de test WebSocket avec montée et descente en charge. Nous n'avons pas vérifié s'il exécute des plugins JMeter comme WebSocket Samplers, nous n'affirmons donc rien à ce sujet.

Comment choisir entre eux ?

Partez du langage de votre équipe, puis demandez-vous si vous testez des WebSockets bruts ou Socket.IO et avec quelle rigueur vous devez vérifier les messages poussés. Il reste en général un ou deux candidats.

Écrivez le même test court de connexion, d'envoi et de réception dans les deux, puis comparez le temps de connexion et la latence des messages à faible charge. Notre guide Comment faire un test de charge détaille les étapes, et le panorama des outils de test de charge open source compare ces projets au-delà des WebSockets.

FAQ

Par quel outil de test de charge WebSocket commencer ? Si votre équipe écrit du JavaScript, commencez par k6, qui intègre WebSocket. Pour les applications Socket.IO, le moteur d'Artillery demande le moins de code, et les équipes JVM seront à l'aise avec Gatling.

JMeter peut-il tester les WebSockets sans plugin ? Sa référence des composants ne cite aucun sampler WebSocket : la voie pratique est donc le plugin WebSocket Samplers, installé via le Plugins Manager ou comme jar dans lib/ext.

Faut-il utiliser k6/ws ou k6/websockets ? Prenez k6/websockets pour les nouveaux tests, comme le recommande la documentation de k6. L'ancien module k6/ws reste documenté pour les scripts existants.

Comment faire un test de charge : le guide pas à pas

Thu, 08 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, un service de test de charge mentionné dans cet article.

Pour faire un test de charge, décidez à quoi ressemble un bon résultat, scriptez un parcours utilisateur réaliste, vérifiez ce script avec un seul utilisateur, puis augmentez la charge par paliers en surveillant les temps de réponse et les erreurs. Comparez ce que vous avez mesuré avec l'objectif fixé au départ, et ne changez qu'une chose à la fois avant le test suivant.

Étape	Ce que vous faites	Terminé quand
1. Fixer l'objectif	Choisir la charge visée et les chiffres qui valent réussite	Vous pouvez écrire les critères en une phrase
2. Scripter un parcours	Transformer un vrai parcours utilisateur en script	Le script tourne sans erreur
3. Test de fumée	Le lancer avec un utilisateur virtuel	Toutes les vérifications passent
4. Monter en charge	Augmenter la charge par paliers et tenir la cible	Vous atteignez la cible ou une condition d'arrêt
5. Lire les résultats	Comparer percentiles et erreurs avec l'objectif	Vous savez si c'est réussi et quoi changer

Que faut-il décider avant de lancer un test de charge ?

Décidez quelle charge vous testez et quel résultat compte comme une réussite. Sans les deux, un test de charge produit des chiffres, mais pas de réponse.

Partez du trafic réel si vous en avez. Vos outils d'analyse ou vos logs d'accès indiquent l'heure la plus chargée, le nombre de requêtes par seconde et les pages ou endpoints qui en reçoivent le plus. Placez la cible au-dessus de ce pic, puisque le but est de savoir que vous avez de la marge. Écrivez ensuite les critères sous forme de chiffres, par exemple : le 95e percentile du temps de réponse reste sous 500 ms et moins de 1 % des requêtes échouent, à 200 utilisateurs virtuels.

Deux décisions pratiques se prennent aussi à ce moment. Choisissez un environnement proche de la production en taille et en configuration, car un serveur de préproduction avec un quart de la capacité en dit peu sur la production. Et assurez-vous d'avoir le droit de le tester : tester un système qui ne vous appartient pas, ou partagé avec d'autres équipes, sans prévenir ressemble exactement à une attaque.

Comment scripter un parcours utilisateur réaliste ?

Scriptez le parcours qui compte le plus pour l'activité, étape par étape, avec des pauses là où une vraie personne lirait ou taperait. Un script qui appelle une seule URL aussi vite que possible mesure quelque chose, mais rarement ce qui vous intéresse.

Pour une boutique, cela peut être : ouvrir l'accueil, chercher, ouvrir un produit, l'ajouter au panier. Pour une API : se connecter, lister des éléments, en récupérer un. Ajoutez une courte pause entre les étapes (temps de réflexion), utilisez des données de test variées pour que les caches se comportent comme en conditions réelles, et vérifiez chaque réponse pour qu'une page d'erreur ne passe pas pour une réponse rapide.

Voici le script utilisé pour l'exemple de ce guide, écrit pour k6. Il monte à 10 utilisateurs virtuels, maintient la charge puis redescend, avec deux critères de réussite intégrés :

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Un vrai parcours comporte plusieurs requêtes et de vraies URL. Celui-ci reste minuscule exprès, pour que les étapes soient faciles à suivre.

Pourquoi lancer d'abord un test de fumée à un seul utilisateur ?

Un test de fumée avec un utilisateur virtuel prouve que le script fonctionne avant de mettre une vraie charge sur quoi que ce soit. C'est le moyen le moins cher de repérer une mauvaise URL, un jeton de connexion manquant ou une vérification qui échoue toujours.

Avec k6, vous pouvez remplacer la charge depuis la ligne de commande, si bien que le même script s'exécute une fois avec un seul utilisateur :

k6 run --vus 1 --iterations 1 script.js

Lors de notre essai, l'unique vérification est passée : le script était prêt pour la charge. Si une vérification échoue à ce stade, corrigez le script avant d'aller plus loin : une erreur à un utilisateur devient du bruit à cent.

Comment augmenter la charge ?

Augmentez la charge par paliers et tenez chaque palier assez longtemps pour qu'il se stabilise, au lieu de sauter directement à la cible. Une montée par paliers montre à partir de quel niveau les choses se dégradent.

Une forme courante consiste à monter à un premier palier, le tenir quelques minutes, monter au suivant, le tenir à nouveau, et ainsi de suite jusqu'à la cible, puis redescendre. En regardant chaque palier séparément, vous voyez si les temps de réponse augmentent régulièrement avec la charge ou restent stables puis décrochent. Ce décrochage, le point où chaque utilisateur supplémentaire ralentit chaque requête, est ce qu'un test de charge peut trouver de plus utile. Notre exemple ne monte qu'à 10 utilisateurs et tient 20 secondes, assez pour montrer les paliers mais bien trop court pour un vrai test.

Que faut-il surveiller pendant le test ?

Surveillez les percentiles du temps de réponse, le taux d'erreur et le débit côté générateur de charge, ainsi que le CPU, la mémoire et la charge de la base de données côté système testé. Les trois premiers indiquent ce que ressentiraient les utilisateurs, les trois derniers expliquent pourquoi.

Fixez des conditions d'arrêt avant de commencer, par exemple : arrêter si le taux d'erreur dépasse 5 % ou si les temps de réponse atteignent plusieurs secondes. Insister sur un système déjà tombé n'apprend rien, et sur un environnement partagé cela gêne le travail des autres.

Surveillez aussi le générateur de charge. S'il tourne à 100 % de CPU, les réponses lentes peuvent venir de votre propre ordinateur plutôt que du serveur.

Comment lire les résultats d'un test de charge ?

Lisez les percentiles et le taux d'erreur au regard des critères notés au départ. Le temps de réponse moyen est le chiffre le moins utile du rapport.

Voici ce qu'a rapporté notre exemple (35 secondes, jusqu'à 10 utilisateurs virtuels, une petite page statique servie sur un portable, le 8 octobre 2026) :

Métrique	Valeur
Requêtes	282 (8 par seconde)
Requêtes en échec	0 %
Temps de réponse moyen	0,69 ms
90e percentile	0,66 ms
95e percentile	0,71 ms
99e percentile	2,68 ms
Requête la plus lente	15,98 ms
Thresholds	Tous deux réussis

Les chiffres sont minuscules parce que la cible était un fichier statique sur la même machine : ce n'est pas un benchmark. La leçon est dans la forme : la moyenne est ressortie au-dessus du 90e percentile, parce qu'une poignée de requêtes lentes l'a tirée vers le haut. Les percentiles décrivent ce qu'a vécu la plupart des requêtes, et le 99e percentile et la requête la plus lente montrent la traîne que subissent quelques utilisateurs. Jugez le test sur le percentile de vos critères, et servez-vous de la traîne pour décider si quelque chose mérite d'être examiné de plus près.

Si un test manque son objectif, changez une seule chose (une requête, un réglage de cache, une taille d'instance) et relancez le même test, pour savoir ce qui a fait la différence.

Quand faut-il lancer le test depuis le cloud ?

Déplacez le générateur de charge dans le cloud quand une seule machine ne peut pas produire la charge nécessaire, ou quand la localisation de vos utilisateurs compte. Un portable sur le Wi-Fi du bureau mesure votre connexion autant que votre serveur.

Le même script k6 peut tourner sur une infrastructure que vous gérez, sur le service hébergé de Grafana, ou sur LoadFocus, qui exécute les scripts k6 depuis 25 régions cloud. Ses rapports détaillent les résultats par localisation et tracent le temps de réponse en fonction du nombre d'utilisateurs virtuels, là où le décrochage décrit plus haut devient visible (lire les résultats dans LoadFocus).

FAQ

Combien de temps doit durer un test de charge ? Assez longtemps pour tenir la charge cible plusieurs minutes après la montée, afin que de brefs pics ne décident pas du résultat. Tenir au moins 10 minutes est un bon point de départ, et bien plus longtemps si vous cherchez des fuites mémoire ou une dégradation lente.

De combien d'utilisateurs virtuels ai-je besoin ? Déduisez-le du trafic réel. Prenez les requêtes par seconde de l'heure la plus chargée, estimez combien de requêtes fait un parcours et combien de temps il dure, et dimensionnez les utilisateurs virtuels pour que le test produise ce débit avec une marge en plus.

Peut-on tester la production sans risque ? C'est possible, avec prudence : tester à une heure calme, prévenir les personnes qui exploitent le système, fixer des conditions d'arrêt et démarrer bien en dessous du pic attendu. Beaucoup d'équipes préfèrent un environnement de préproduction de la taille de la production, pour qu'un test raté ne touche aucun client.

k6 vs Artillery : quel outil de test de charge choisir ?

Thu, 08 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

k6 et Artillery sont deux outils de test de charge open source où les tests s'écrivent sous forme de code, et l'un comme l'autre testera correctement une API HTTP sous charge. Choisissez k6 si vous voulez un binaire unique, une logique de test en JavaScript et des seuils de réussite intégrés. Choisissez Artillery si votre équipe vit déjà dans Node.js, préfère des scénarios YAML courts, ou veut des tests navigateur avec Playwright et des exécutions distribuées sur AWS ou Azure depuis la ligne de commande.

Les informations ci-dessous viennent de la documentation et du dépôt de chaque projet, vérifiées le 8 octobre 2026.

	k6	Artillery
Licence	AGPL-3.0 (dépôt)	MPL-2.0, certains modules Azure sous BSL (dépôt)
Environnement d'exécution	Un binaire Go avec un moteur JavaScript intégré	Node.js, dernière version LTS
Scripts de test	JavaScript	YAML, TypeScript ou JavaScript
Protocoles principaux	HTTP, WebSockets, gRPC	HTTP, WebSocket, Socket.IO (gRPC et Kinesis via des moteurs additionnels)
Tests navigateur	Module navigateur intégré	Playwright
Critères de réussite	Thresholds	Plugin `ensure`
Montée en charge distribuée	k6-operator sur Kubernetes, ou Grafana Cloud k6	`run-lambda` ou `run-fargate` sur AWS, `run-aci` sur Azure

Quelle est la différence entre k6 et Artillery ?

Ils diffèrent surtout par leur environnement d'exécution et par la façon de décrire la charge. k6 est un outil Go compilé qui exécute du code de test JavaScript, alors qu'Artillery est un outil Node.js qui lit des scénarios YAML ou JavaScript.

Cette différence se voit dès le premier jour. Installer k6 revient à installer un paquet ou un binaire autonome, sans environnement d'exécution à maintenir. Artillery a besoin de Node.js et s'installe avec npm, ce qui est naturel dans un projet JavaScript et ajoute un environnement de plus à tenir à jour partout ailleurs.

Côté protocoles, le socle commun couvre l'essentiel du travail web : les deux parlent HTTP et WebSockets d'origine. k6 fournit aussi gRPC, et Artillery Socket.IO. Artillery obtient gRPC et Kinesis par des moteurs additionnels à installer séparément (vérifié le 9 octobre 2026), et k6 va plus loin grâce à son écosystème d'extensions.

Comment écrit-on un test avec chaque outil ?

Avec k6, vous écrivez un module JavaScript avec les options en haut et une fonction par défaut que chaque utilisateur virtuel exécute. Avec Artillery, vous écrivez le plus souvent un fichier YAML avec un bloc config pour la charge et un bloc scenarios pour ce que fait chaque utilisateur virtuel.

Un test k6 qui monte à 20 utilisateurs virtuels et échoue si le 95e percentile du temps de réponse dépasse 500 ms :

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m", target: 20 },
    { duration: "15s", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<500"] },
};

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

La même idée dans le format YAML d'Artillery, avec dix nouveaux utilisateurs virtuels par seconde pendant une minute :

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Les deux exemples modélisent la charge différemment. Le script k6 fixe un nombre d'utilisateurs virtuels simultanés, et le fichier Artillery fixe combien de nouveaux utilisateurs virtuels arrivent chaque seconde. k6 sait aussi piloter un taux d'arrivée grâce à ses executors de scénarios, et Artillery peut plafonner la concurrence avec maxVusers : choisissez donc le modèle qui correspond à la façon dont le vrai trafic arrive sur votre système, plutôt que celui que chaque outil montre en premier.

Comment k6 et Artillery décident-ils qu'un test a réussi ?

Les deux traduisent un objectif de performance en code de sortie, ce dont un pipeline CI a besoin. Un objectif manqué termine l'exécution avec un code de sortie non nul dans les deux outils.

Dans k6, les objectifs s'appellent des thresholds et se placent dans les options du script, comme dans l'exemple ci-dessus. Dans Artillery, ils se trouvent dans le plugin ensure, qui accepte des seuils simples et des conditions combinant plusieurs métriques.

La différence pratique tient à l'endroit où vivent les objectifs. Les thresholds de k6 sont dans le même fichier que la logique de test. Les vérifications d'Artillery sont dans le bloc config, où quelqu'un qui ne touche jamais aux scénarios peut quand même les ajuster.

Comment lancer un test plus gros qu'une seule machine ne peut générer ?

Les deux outils savent répartir un test sur plusieurs machines, par des chemins très différents. k6 s'appuie sur Kubernetes ou sur le service hébergé de Grafana, et Artillery sur votre propre compte AWS ou Azure.

Pour k6, le k6-operator répartit un test sur des pods d'un cluster Kubernetes, et Grafana Cloud k6 exécute les mêmes scripts en tant que service hébergé. Pour Artillery, les commandes run-lambda et run-fargate lancent des workers dans votre compte AWS après une configuration IAM unique via une pile CloudFormation. Sur Azure, run-aci fait de même avec Azure Container Instances, mais exige un abonnement payant à Artillery au-delà d'une évaluation (vérifié le 9 octobre 2026). Si vous utilisez déjà Kubernetes, la voie de l'operator vous semblera familière. Si vous préférez ne rien exploiter vous-même, la voie serverless d'Artillery a moins de pièces mobiles, à condition que le test puisse tourner dans AWS ou Azure.

Il existe une troisième voie pour les scripts k6. LoadFocus exécute les scripts k6 sur sa propre infrastructure cloud depuis 25 régions, si bien que le script lancé sur votre portable devient un test distribué sans cluster ni compte AWS. LoadFocus n'exécute pas les scripts Artillery : pour Artillery, ses propres commandes AWS et Azure restent le moyen de monter en charge.

Où vont les résultats ?

Les deux outils affichent un résumé à la fin d'une exécution et peuvent envoyer leurs métriques vers d'autres systèmes pour les tableaux de bord et les alertes.

D'après son dépôt, k6 propose des statistiques résumées ou des métriques détaillées exportées vers le service de votre choix. Artillery annonce dans son dépôt plus de 20 intégrations pour le monitoring, l'observabilité et la CI/CD. Les deux peuvent donc alimenter les tableaux de bord que vous avez déjà. Vérifiez avant de vous engager que la sortie précise dont vous avez besoin figure dans la liste, car les deux listes changent d'une version à l'autre.

Lequel choisir ?

Choisissez k6 si vous voulez un binaire unique dans la CI, une logique de test JavaScript avec un vrai flux de contrôle, et des thresholds dans le même fichier que le test. Il convient aussi aux équipes qui utilisent déjà Grafana, puisque l'outil open source et le service hébergé partagent la même API de script.

Choisissez plutôt Artillery si votre équipe écrit du Node.js tous les jours, si un court fichier YAML est plus facile à relire pour le reste de l'équipe qu'un script, ou si vous avez besoin de tests navigateur Playwright et de Socket.IO dans le même outil. Sa montée en charge serverless est aussi le chemin le plus court si votre infrastructure vit déjà dans AWS et que Kubernetes n'en fait pas partie.

Si vous hésitez encore, écrivez le même test de fumée dans les deux outils. Vingt lignes suffisent pour voir lequel votre équipe lit le plus facilement en revue de code.

FAQ

k6 est-il gratuit ? Oui. k6 est open source sous licence AGPL-3.0 et tourne gratuitement sur vos propres machines. Grafana Cloud k6 est un service hébergé distinct, avec sa propre tarification.

Artillery est-il gratuit ? En grande partie. L'essentiel d'Artillery est sous licence MPL-2.0, mais certains modules propres à Azure utilisent une licence source-available qui exige une licence commerciale pour un usage en production sur Azure, selon le dépôt du projet (vérifié le 8 octobre 2026).

LoadFocus peut-il exécuter des tests Artillery ? Non. LoadFocus exécute des scripts k6 et JMeter. Pour faire monter un test Artillery au-delà d'une machine, utilisez les commandes d'Artillery pour AWS Lambda, Fargate ou Azure Container Instances dans votre propre compte cloud.

Quel outil consomme le moins de ressources sur le générateur de charge ? Nous ne l'avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. Le projet k6 indique que même des machines modestes peuvent simuler beaucoup de trafic, et la seule comparaison honnête consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Outils de test de charge open source : six options

Thu, 08 Oct 2026 00:00:00 GMT

Transparence : loadtest.app est publié par LoadFocus, qui vend un service de test de charge présenté dans cet article.

Six outils de test de charge open source très utilisés aujourd'hui sont Apache JMeter, k6, Gatling, Locust, Artillery et Vegeta. Choisissez selon le langage dans lequel votre équipe écrit ses tests et selon la façon dont vous devez monter en charge : JMeter pour la plus large couverture de protocoles, k6 ou Artillery pour JavaScript, Gatling pour la JVM, Locust pour Python et Vegeta pour des vérifications HTTP rapides à débit fixe.

Pour cet article, nous n'avons pas comparé ces outils entre eux par des benchmarks. Les informations viennent du dépôt et de la documentation de chaque projet, vérifiées le 8 octobre 2026, et les mentions « Idéal pour » sont notre jugement.

Outil	Licence	Tests écrits en	Tourne sur	Répartir la charge sur plusieurs machines
Apache JMeter	Apache 2.0	Plans de test construits dans une interface graphique	Java	Mode distant (client-serveur) intégré
k6	AGPL-3.0	JavaScript	Un binaire Go	k6-operator sur Kubernetes
Gatling	Apache 2.0 (certains composants sous licence entreprise)	Java, Kotlin, Scala, JavaScript, TypeScript	JVM	Édition Enterprise commerciale
Locust	MIT	Python	Python	Intégré
Artillery	MPL-2.0 (certains modules Azure sous BSL)	YAML, JavaScript, TypeScript	Node.js	AWS Lambda, Fargate ou Azure ACI depuis la CLI
Vegeta	MIT	Ligne de commande ou code Go	Un binaire Go	Lancer plusieurs instances

Apache JMeter vaut-il encore la peine ?

Oui, surtout si vous avez besoin de protocoles au-delà de HTTP. JMeter couvre le plus large éventail des six et s'appuie sur le plus grand stock de plans de test et de savoir-faire existants.

JMeter est une application Java sous licence Apache 2.0. Sa liste de protocoles couvre HTTP et HTTPS, les services web SOAP et REST, FTP, les bases de données via JDBC, LDAP, la messagerie JMS, le courrier et le TCP brut. Vous construisez les plans de test dans une interface graphique, vous les lancez sans interface depuis la ligne de commande pour les vrais tests, et le mode distant client-serveur répartit un test sur plusieurs machines.

Idéal pour les systèmes multiprotocoles, les équipes qui ont déjà des plans JMeter et les testeurs qui préfèrent construire leurs tests visuellement. Choisissez autre chose si votre équipe veut des tests en code pur, relus comme l'application, car des plans XML construits dans une interface graphique sont difficiles à lire dans une pull request.

Quand k6 est-il le bon choix ?

Quand votre équipe écrit du JavaScript et veut des tests en code avec des seuils de réussite intégrés. k6 est livré sous forme d'un binaire Go unique, ce qui simplifie sa mise en place en CI.

k6 est sous licence AGPL-3.0 et parle HTTP, WebSockets et gRPC, avec un module navigateur pour les vérifications front-end. Les thresholds transforment un objectif, comme une limite sur le 95e percentile, en code de sortie non nul pour la CI. Pour monter en charge, le k6-operator exécute des tests distribués sur Kubernetes, et Grafana vend un service hébergé.

Idéal pour les développeurs qui gardent leurs tests d'API à côté du code, et pour les pipelines CI. Choisissez autre chose si votre équipe ne veut pas de JavaScript, ou si la licence AGPL ne convient pas à la façon dont vous intégrez ou distribuez l'outil. Nous le comparons en détail dans k6 vs Artillery.

À qui s'adresse Gatling ?

Aux équipes sur la JVM qui veulent des tests en code et un rapport HTML détaillé sans rien ajouter. Il propose aussi un SDK JavaScript et TypeScript sur le même moteur.

Gatling fait tourner les utilisateurs virtuels sur un moteur non bloquant construit sur Netty, si bien qu'une seule machine peut générer beaucoup de charge. Les simulations s'écrivent en Java, Kotlin, Scala, JavaScript ou TypeScript et se lancent via des plugins Maven, Gradle, sbt ou npm. L'édition communautaire est sous Apache 2.0 et couvre HTTP/1.1, HTTP/2, WebSocket, les Server-Sent Events et JMS, tandis que ses composants gRPC, MQTT et GraphQL relèvent de la licence entreprise de Gatling.

Idéal pour les équipes Java et Scala, et pour quiconque veut des rapports riches sans outillage supplémentaire. Choisissez autre chose si vous devez répartir la charge sur plusieurs machines avec la seule édition open source : générer la charge depuis une infrastructure gérée ou privée est le rôle de Gatling Enterprise, l'édition commerciale.

Locust est-il un bon choix pour les équipes Python ?

Oui. Les tests Locust sont du Python pur : boucles, conditions et n'importe quelle bibliothèque Python fonctionnent comme dans du code ordinaire.

Locust est sous licence MIT et fonctionne de manière événementielle avec gevent, ce qui permet à un seul processus de gérer beaucoup d'utilisateurs. Les tests se lancent en ligne de commande ou depuis une interface web qui affiche en direct le débit, les temps de réponse et les erreurs, et Locust répartit un test sur plusieurs machines de lui-même. HTTP est intégré, et les autres protocoles s'ajoutent en écrivant du Python.

Idéal pour les équipes Python, les scénarios à logique complexe et ceux qui aiment suivre un test dans le navigateur. Choisissez autre chose si vous voulez des tests déclaratifs façon configuration, ou si un plugin prêt à l'emploi pour un protocole inhabituel compte plus que d'en écrire un vous-même.

Quand Artillery a-t-il du sens ?

Quand votre équipe vit dans Node.js, aime les scénarios YAML courts, ou veut des tests navigateur Playwright dans le même outil que ses tests d'API.

Artillery est principalement sous MPL-2.0, avec certains modules Azure sous une licence source-available. Il gère d'origine HTTP, WebSocket et Socket.IO, ajoute gRPC et Kinesis par des moteurs additionnels, et ses commandes run-lambda et run-fargate répartissent un test sur des workers dans votre propre compte AWS. La commande run-aci fait de même sur Azure Container Instances, avec un abonnement payant à Artillery au-delà d'une évaluation (vérifié le 9 octobre 2026).

Idéal pour les équipes Node.js, les tests mixtes API et navigateur, et les entreprises déjà sur AWS. Choisissez autre chose si vous préférez ne pas installer Node.js sur vos générateurs de charge, ou si de gros tests doivent tourner hors d'AWS et d'Azure.

À quoi sert Vegeta ?

À des vérifications HTTP rapides, à débit constant, depuis la ligne de commande. Il fait une seule chose, envoyer des requêtes à débit fixe, et la garde simple.

Vegeta est un outil Go sous licence MIT qui fonctionne comme programme en ligne de commande ou comme bibliothèque Go, avec une CLI pensée pour se combiner avec les autres outils Unix. Comme il maintient le débit de requêtes constant au lieu de modéliser des utilisateurs, il répond mieux à des questions comme « que se passe-t-il à 500 requêtes par seconde ? » qu'il ne reproduit des parcours utilisateurs.

Idéal pour vérifier rapidement un endpoint, faire des tests de capacité à débit fixe et écrire des scripts shell. Choisissez autre chose si vous avez besoin de parcours en plusieurs étapes, de temps de réflexion ou de rapports détaillés.

Où se situe un service hébergé comme LoadFocus ?

Aucun de ces outils n'a besoin d'un service hébergé, mais générer une charge importante ou répartie géographiquement depuis vos propres machines demande du travail. Un service hébergé prend en charge la génération de charge et laisse vos scripts tels quels.

LoadFocus, l'éditeur de ce site, est l'un de ces services. Il exécute vos plans de test JMeter existants et vos scripts k6 depuis 25 régions cloud. Il n'exécute pas les tests Gatling, Locust, Artillery ou Vegeta : pour ces outils, les options de montée en charge décrites plus haut s'appliquent. Grafana Cloud k6 et Gatling Enterprise sont les voies hébergées des éditeurs eux-mêmes pour k6 et Gatling.

Comment choisir entre eux ?

Partez du langage que votre équipe écrit déjà et des protocoles à tester, puis regardez comment chaque outil monte en charge. Cela ramène généralement six options à une ou deux.

Écrivez ensuite le même petit test avec vos deux favoris. Les lire côte à côte tranche la plupart des débats plus vite que n'importe quel tableau comparatif, et notre guide Comment faire un test de charge accompagne ce premier test pas à pas.

FAQ

Quel outil de test de charge open source est le plus simple pour débuter ? Pour un seul endpoint HTTP, Vegeta ou k6 donnent un résultat en quelques minutes, car chacun tient en un seul binaire. Pour des parcours en plusieurs étapes, prenez l'outil dont le langage de test est déjà celui de votre équipe.

Les outils de test de charge open source peuvent-ils lancer des tests distribués ? Oui, par des voies différentes : JMeter a un mode distant intégré, Locust se répartit nativement sur plusieurs machines, k6 utilise le k6-operator sur Kubernetes et Artillery utilise AWS Lambda, Fargate ou Azure Container Instances. Pour Gatling, générer la charge depuis une infrastructure gérée ou privée fait partie de l'édition commerciale Enterprise.

JMeter est-il meilleur que k6 ? Aucun n'est meilleur dans l'absolu. JMeter couvre plus de protocoles et convient à la conception de tests en interface graphique, tandis que k6 convient aux développeurs qui veulent des tests en code JavaScript dans la CI.

loadtest.app

Loi d'Amdahl : formule, exemples et limites

Que dit la loi en termes simples ?

D'où vient cette loi ?

Qu'est-ce que cela change pour les tests de charge et de capacité ?

Comment trouver la part séquentielle dans un test de charge ?

Qu'est-ce que la loi de Gustafson ?

Qu'apporte l'Universal Scalability Law ?

Comment ajuster l'USL sur une série de tests de charge ?

Où ces modèles cessent-ils d'être utiles ?

FAQ

À lire aussi

Théorie des files d'attente : ce qu'elle dit de la latence

Qu'est-ce que la théorie des files d'attente ?

D'où vient la théorie des files d'attente ?

Que signifie la notation de Kendall, comme M/M/1 ?

Comment le temps de réponse augmente-t-il avec le taux d'utilisation ?

Pourquoi la latence fait-elle un coude avant que le CPU atteigne 100 % ?

Pourquoi la variabilité compte-t-elle autant que le taux d'utilisation ?

Comment plusieurs serveurs (M/M/c) aident-ils ?

Quel lien avec la loi de Little ?

Où ces modèles cessent-ils de s'appliquer en test de charge ?

FAQ

À lire aussi

SLO vs SLA : la différence, les SLI et le budget d'erreur

Que signifient SLI, SLO et SLA ?

Qu'est-ce qu'un budget d'erreur ?

Combien d'indisponibilité permet 99,9 % ?

À quoi ressemble un vrai SLA ?

Comment choisir des SLI pour la latence et la disponibilité ?

Où les SLO dérapent-ils ?

Quel rapport entre le test de charge et les SLO ?

FAQ

À lire aussi

TPC-H : ce que mesure le benchmark et comment le lancer

Que mesure TPC-H ?

Comment le score TPC-H est-il calculé ?

Qui publie les résultats TPC-H, et lesquels comptent ?

Comment lancer TPC-H vous-même ?

Comment lire honnêtement des résultats TPC-H ?

Quand utiliser autre chose que TPC-H ?

FAQ

À lire aussi

pgbench : benchmark et test de charge de PostgreSQL

Que mesure pgbench ?

Comment préparer une base pour pgbench ?

Quels scripts intégrés pgbench propose-t-il ?

Comment écrire un script pgbench personnalisé ?

Quelles options font de pgbench un test de charge ?

Comment lire la sortie de pgbench ?

Comment obtenir des chiffres pgbench fiables ?

Quand pgbench n'est-il pas le bon outil ?

FAQ

À lire aussi

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

Comment lancer redis-benchmark ?

Comment lire la sortie de redis-benchmark ?

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

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

Comment mesurer votre propre commande ou un script Lua ?

Pourquoi votre application voit-elle d'autres chiffres ?

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

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

FAQ

À lire aussi

Utiliser sysbench : benchmarks CPU, disque et MySQL

sysbench est-il encore maintenu ?

Comment se déroule une exécution de sysbench ?

Comment mesurer le CPU et la mémoire avec sysbench ?

Comment tester MySQL ou PostgreSQL avec sysbench ?

Quelles options de sysbench comptent le plus ?

sysbench suit-il un modèle de charge fermé ou ouvert ?

Comment lire les résultats de sysbench ?

Quand sysbench n'est-il pas le bon outil ?

FAQ

À lire aussi

YCSB : charges de travail A-F, exécution et limites

Qu'est-ce que YCSB, et est-il encore maintenu ?

Comment lancer un benchmark YCSB ?

Que règlent -threads et -target ?