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

9 octobre 2026 8 min de lecture

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.