Files d'attente et dimensionnement

Un serveur qui traite dix requêtes par seconde et qui en reçoit neuf n'est pas « chargé à 90 % » au sens où l'on chargerait un camion à 90 %. Il est chargé au point où la file devient neuf fois plus longue qu'à moitié charge, et où le temps de réponse a quintuplé. Cette non-linéarité n'est pas une bizarrerie : c'est la loi qui gouverne tout système où des demandes arrivent au hasard.

Ce chapitre installe le modèle le plus simple qui la capture, et les trois quantités qu'il faut savoir calculer avant de dimensionner quoi que ce soit : le taux d'occupation, la longueur de la file et le temps de réponse.

Ce qu'une file d'attente modélise

Trois ingrédients suffisent à décrire la plupart des situations d'attente, et ils se posent avant tout calcul.

Les trois ingrédients

Le processus d'arrivée dit à quel rythme les demandes se présentent. On note $\lambda$ le nombre moyen d'arrivées par unité de temps.

Le processus de service dit à quel rythme une demande est traitée. On note $\mu$ le nombre moyen de demandes qu'un serveur peut traiter par unité de temps.

La discipline dit dans quel ordre les demandes passent : premier arrivé premier servi, le plus court d'abord, par priorité.

Le cas de référence porte un nom codé, M/M/1 : arrivées sans mémoire, service sans mémoire, un seul serveur. « Sans mémoire » veut dire que le temps qui sépare deux arrivées ne dépend pas de ce qui s'est passé avant, ce qui décrit correctement un trafic de clients indépendants les uns des autres.

Le débit d'un système n'est pas sa capacité

Un serveur qui traite 10 requêtes par seconde au maximum et qui en reçoit 9 délivre bien 9 requêtes par seconde. Son débit vaut donc 9, et il vaut aussi 9 si le serveur pouvait en traiter 1 000.
Le débit ne dit rien de l'attente. Deux systèmes de débit identique peuvent avoir des temps de réponse dans un rapport de dix, et c'est le taux d'occupation qui les sépare.

Le taux d'occupation

Définition

Le taux d'occupation $\rho$ est le rapport du rythme d'arrivée au rythme de service :

\rho = \frac{\lambda}{\mu}

C'est la fraction du temps pendant laquelle le serveur travaille. Le système n'est stable que si $\rho < 1$ .

La condition de stabilité mérite d'être lue lentement. Si $\rho \geq 1$ , il arrive en moyenne plus de demandes que le serveur n'en traite : la file grandit sans limite, et aucune valeur moyenne n'existe. Ce n'est pas une file longue, c'est une file infinie.

Un serveur occupé à 100 % n'est pas un serveur bien utilisé

C'est un serveur dont la file diverge. Le viser revient à demander qu'il n'y ait jamais le moindre creux, et le moindre à-coup d'arrivée se paie alors par une attente qui ne se résorbe pas.
Toute la difficulté du dimensionnement tient dans cet écart : le taux d'occupation qu'on aimerait viser pour amortir la machine, et celui qu'on peut se permettre sans dégrader le service.

La loi de Little

Une seule relation lie les trois quantités qu'on cherche, et elle ne suppose presque rien.

Loi de Little

L = \lambda \times W

où $L$ est le nombre moyen de demandes présentes dans le système et $W$ le temps moyen qu'une demande y passe.

Sa portée est plus grande que sa simplicité ne le laisse croire : elle ne suppose ni une loi d'arrivée particulière, ni une discipline particulière, ni même un seul serveur. Elle vaut dès que le système est stable et observé assez longtemps.

L'usage est toujours le même : mesurer les deux quantités faciles, et en déduire la troisième. Le rythme d'arrivée se compte, le nombre de demandes présentes se relève, et le temps de réponse, qui est le plus pénible à instrumenter, s'en déduit sans le mesurer.

La file d'un seul serveur

Pour le cas M/M/1, deux formules donnent tout le reste.

Les deux formules à connaître

L = \frac{\rho}{1 - \rho} \qquad\qquad W = \frac{1}{\mu - \lambda}

$L$ compte les demandes présentes, celle en cours de traitement comprise. $W$ mesure le temps total passé dans le système, attente et service compris.

Le dénominateur est ce qui compte. Dans les deux formules, il tend vers zéro quand la charge approche la capacité, et c'est de là que vient l'explosion.

La formule le dit, la figure ci-dessous le fait voir. Les clients arrivent au hasard, le serveur les traite au hasard, et rien n'est recopié depuis la théorie : la moyenne affichée est mesurée sur ce qui se passe à l'écran, et la valeur théorique s'affiche à côté pour que les deux se rejoignent.

λ = 8μ = 10c = 1ρ = 0,8

en attente0temps simulé0 sprésents, mesuré0/ 4séjour, mesuré0 ms/ 500 msattente en file400 msrisque d'attendre80 %

Mesure encore trop courte pour être comparée : 0 clients servis. Laisser tourner, ou accélérer, jusqu'à la centaine. Un écart entre la mesure et la théorie avant ce point ne dit rien de la théorie, il dit seulement qu'on n'a pas assez regardé.

Une file à un serveur, qui tourne en temps réel. Les ronds sont les clients en attente, le carré est le serveur, et le tracé du bas suit le nombre de présents. Le trait orange est la moyenne que le modèle prédit.

À manipuler

Appuyer sur « accélérer ×20 » et laisser tourner jusqu'à ce que l'avertissement de mesure courte disparaisse : la moyenne mesurée rejoint alors la moyenne théorique, et le tracé oscille autour du trait orange. Le temps qu'il y faut est déjà une leçon, car il dit ce que vaut une mesure de dix secondes.
Monter ensuite λ à 9, puis à 9,5, sans toucher à μ. La file met de plus en plus de temps à se vider, et les creux où le serveur chôme disparaissent. Chercher la valeur de λ à partir de laquelle la file ne redescend plus jamais à zéro pendant l'observation.
Pousser enfin λ au-delà de μ. Le trait orange disparaît, parce qu'il n'y a plus de moyenne à annoncer, et le tracé monte sans jamais redescendre. Accélérer alors ×20 pour voir à quelle vitesse la situation devient irrattrapable.

f(x) = x / (1 - x)

La longueur moyenne de la file en fonction du taux d'occupation. Jusqu'à 0,7 la courbe est presque plate ; au-delà de 0,9 elle devient verticale. C'est la même courbe pour le temps de réponse, à un facteur près.

La figure dit ce qu'aucune formule ne fait sentir. Entre 0 et 0,7, la file reste sous deux demandes et le système paraît confortable. Entre 0,9 et 0,95, elle passe de 9 à 19 : doubler, pour cinq points de charge de plus.

Un serveur à 10 requêtes par seconde

Un service traite au plus 10 requêtes par seconde. Voici ce que devient la file selon le trafic reçu.

Trafic $\lambda$	Occupation $\rho$	File $L$	Temps de réponse $W$
5	0,50	1,0	200 ms
8	0,80	4,0	500 ms
9	0,90	9,0	1 000 ms
9,5	0,95	19,0	2 000 ms
9,9	0,99	99,0	10 000 ms

Passer de 5 à 9 requêtes par seconde multiplie le trafic par 1,8 et le temps de réponse par 5. Passer de 9 à 9,9 le multiplie encore par 1,1 et le temps de réponse par 10.

Plusieurs serveurs pour une seule file

Devant un service trop lent, deux leviers existent, et l'intuition se trompe sur lequel rend le plus.

Accélérer le serveur augmente $\mu$ . Ajouter des serveurs augmente leur nombre $c$ , chacun gardant son propre rythme. À capacité totale identique, $c\mu$ constant, les deux organisations n'ont pas du tout le même comportement.

Le taux d'occupation avec plusieurs serveurs

\rho = \frac{\lambda}{c\,\mu}

C'est la fraction du temps pendant laquelle un serveur donné travaille. La condition de stabilité reste $\rho < 1$ , et elle porte maintenant sur la capacité totale.

La probabilité qu'un client arrivant trouve tous les serveurs occupés, et doive donc attendre, porte un nom et une formule : c'est la formule d'Erlang C. Elle ne s'apprend pas par cœur, elle se calcule, et ce qu'elle produit vaut la peine d'être regardé.

Organisation	$\rho$	Risque d'attendre	Attente en file	Temps total
1 serveur à 10/s, $\lambda = 8$	0,80	80 %	400 ms	500 ms
2 serveurs à 10/s, $\lambda = 16$	0,80	71 %	178 ms	278 ms
3 serveurs à 10/s, $\lambda = 24$	0,80	65 %	108 ms	208 ms

Les trois lignes ont le même taux d'occupation et des attentes dans un rapport de quatre. C'est l'effet de mutualisation : plus il y a de serveurs derrière une même file, moins il est probable qu'ils soient tous occupés au même instant, et moins il faut attendre.

λ = 16μ = 10c = 2ρ = 0,8

en attente0temps simulé0 sprésents, mesuré0/ 4,44séjour, mesuré0 ms/ 278 msattente en file178 msrisque d'attendre71 %

Deux serveurs derrière une seule file. Le curseur c change leur nombre : à taux d'occupation constant, passer de un à trois serveurs divise l'attente par quatre sans qu'aucun serveur n'aille plus vite.

À manipuler

Régler λ = 8, μ = 10, c = 1, puis λ = 16 et c = 2, puis λ = 24 et c = 3. Le taux d'occupation reste à 0,80 dans les trois cas, et l'attente en file tombe de 400 à 108 millisecondes. Rien n'a été accéléré : seule la mutualisation a joué.
Chercher ensuite le contre-exemple : à c = 1 et μ = 20, la capacité totale vaut aussi 20, et pourtant l'attente en file remonte à 200 millisecondes. Mais le temps TOTAL, lui, descend à 250. Les deux organisations ne gagnent pas la même chose.

Un gros serveur ou plusieurs petits : la réponse dépend de ce qu'on mesure

Avec

\lambda = 16

et une capacité totale de 20 par seconde, deux serveurs à 10 donnent 178 millisecondes d'attente en file contre 200 pour un serveur unique à 20. Les deux serveurs gagnent.
Mais le temps total ajoute la durée du service, qui vaut 100 millisecondes sur un serveur lent contre 50 sur le rapide. Le total devient 278 contre 250 : le serveur unique gagne.
La conclusion dépend donc de la question posée. Si le service est long et l'attente courte, le serveur rapide l'emporte. Si l'attente domine, la mutualisation l'emporte. Et dans la vie réelle, un troisième critère tranche souvent : deux serveurs survivent à la panne de l'un des deux.

Une file commune, pas une file par serveur

C'est la raison pour laquelle les guichets de banque et les contrôles d'aéroport ont abandonné la file par guichet. Avec des files séparées, un serveur peut chômer pendant que quelqu'un attend ailleurs, et ce gaspillage ne se rattrape jamais.
Le gain est d'autant plus grand que la charge est élevée : c'est exactement là où les creux d'un serveur et les pointes d'un autre ont le plus de chances de tomber en même temps.

La moyenne ne suffit pas : les centiles

Un temps de réponse moyen de 500 millisecondes ne dit pas ce que subit l'utilisateur le plus malchanceux, et c'est pourtant lui qui écrit à l'assistance.

Dans le modèle à un serveur, le temps passé dans le système suit une loi exponentielle de paramètre $\mu - \lambda$ . La proportion de clients qui attendent plus de $t$ vaut donc

P(W > t) = e^{-(\mu - \lambda)\,t}

Cette forme a une conséquence directe : les centiles se calculent en une ligne, sans simulation.

La distribution derrière une moyenne de 500 millisecondes

Pour $\mu = 10$ et $\lambda = 8$ , donc $\mu - \lambda = 2$  :

Quantité	Valeur
Moyenne	500 ms
Médiane	347 ms
90^e centile	1 151 ms
95^e centile	1 498 ms
99^e centile	2 303 ms

La médiane est inférieure à la moyenne, et le centile 99 vaut 4,6 fois la moyenne.

Ce que cela impose à un engagement de service

Un engagement écrit sur la moyenne est presque toujours une erreur : la moitié des clients font mieux que la médiane, qui est déjà sous la moyenne, pendant qu'un centième subit près de cinq fois la moyenne annoncée.
Les engagements sérieux portent donc sur un centile, et le rapport de 4,6 ci-dessus donne l'ordre de grandeur du coût : promettre un centile 99 à 500 millisecondes revient à viser une moyenne autour de 110, donc une capacité bien supérieure.

La variabilité pèse autant que la charge

Le modèle suppose des services de durée très variable, puisqu'une loi sans mémoire l'est. Beaucoup de services réels ne le sont pas : une requête de base de données sur index prend presque toujours le même temps.

Une approximation due à Kingman donne l'attente en file pour des lois quelconques :

W_q \approx \frac{\rho}{1 - \rho} \times \frac{c_a^2 + c_s^2}{2} \times \frac{1}{\mu}

où $c_a$ et $c_s$ sont les coefficients de variation des intervalles entre arrivées et des durées de service, c'est-à-dire leur écart-type divisé par leur moyenne. Un processus sans mémoire a un coefficient de 1 ; un service parfaitement régulier a un coefficient de 0.

Situation	$c_a$	$c_s$	Attente en file à $\rho = 0{,}8$
Arrivées et service sans mémoire	1	1	400 ms
Service parfaitement régulier	1	0	200 ms
Arrivées régulières, service sans mémoire	0	1	200 ms
Service très variable	1	2	1 000 ms

Régulariser vaut une augmentation de capacité

Rendre le service parfaitement régulier divise l'attente par deux, sans ajouter la moindre machine. À l'inverse, un service dont la durée varie deux fois plus que la moyenne multiplie l'attente par 2,5.
C'est le levier le moins cher et le plus souvent oublié. Découper un traitement long en morceaux réguliers, séparer les requêtes lourdes des légères dans deux files distinctes, plafonner la taille d'un lot : toutes ces mesures réduisent

c_s

, et elles agissent sur l'attente aussi fortement qu'un serveur de plus.

La discipline change qui attend, pas combien

Premier arrivé premier servi, dernier arrivé premier servi, au hasard : ces trois disciplines donnent exactement la même longueur moyenne de file et le même temps d'attente moyen.

La raison est simple une fois vue : tant que la discipline ne regarde pas la durée du service et ne laisse jamais un serveur inoccupé devant une file non vide, le nombre de clients présents suit la même loi. La loi de Little fait le reste.

Ce qui change, et radicalement, c'est la distribution. En premier arrivé premier servi, tout le monde attend à peu près pareil. En dernier arrivé premier servi, la plupart sont servis tout de suite et quelques-uns attendent très longtemps. Même moyenne, expériences opposées.

Servir le plus court d'abord réduit vraiment la moyenne, et affame les autres

Une discipline qui regarde la durée du service échappe au résultat précédent. Servir le plus court d'abord minimise le temps d'attente moyen, et c'est un théorème.
Le prix est que les tâches longues peuvent ne jamais passer, tant qu'il arrive des tâches courtes. Un ordonnanceur qui l'emploie doit donc lui ajouter un vieillissement : au bout d'un certain temps d'attente, la priorité d'une tâche monte, quelle que soit sa durée.

Le paradoxe de l'attente

Les bus passent toutes les dix minutes en moyenne, mais à des instants irréguliers. Une personne qui arrive à l'arrêt sans consulter l'horaire attend en moyenne dix minutes, et non cinq.

Ce n'est pas une erreur de calcul, c'est un effet de sélection. Arriver à un instant quelconque rend plus probable de tomber dans un grand intervalle que dans un petit, précisément parce qu'il est plus grand. L'intervalle qui contient un instant pris au hasard est donc en moyenne deux fois plus long que l'intervalle moyen.

Où ce biais se rencontre ailleurs

Il porte le nom de paradoxe de l'inspection, et il frappe toutes les mesures prises « à un instant quelconque ».
Un sondage sur la taille des classes mené auprès des élèves donne une taille moyenne supérieure à celle que donne le même sondage mené auprès des établissements, parce qu'une grande classe contient plus d'élèves à interroger. Un relevé de la durée des requêtes pris au hasard dans un journal surreprésente les requêtes longues, pour la même raison. Dans les deux cas, le nombre obtenu est juste et ne répond pas à la question posée.

Quand les files se suivent

Un système réel enchaîne rarement une seule file. Une requête traverse un répartiteur, puis un serveur applicatif, puis une base de données, et chacun est une file.

Deux résultats suffisent à raisonner sur l'ensemble.

Le débit de la chaîne est celui de son étage le plus lent, et d'aucun autre. Accélérer un étage qui n'est pas le goulet ne change rien au débit total : cela ne fait que déplacer l'attente en amont du goulet.

La loi de Little s'applique à l'ensemble comme à chaque étage. Le nombre de requêtes présentes dans tout le système, divisé par le débit, donne le temps de traversée complet, sans qu'il soit besoin de décomposer.

Identifier le goulet avant d'optimiser quoi que ce soit

Le goulet est l'étage dont le taux d'occupation est le plus élevé, et c'est le seul dont l'accélération se voit de bout en bout. Optimiser ailleurs est un travail perdu, et cela se démontre avant de coder : il suffit de calculer

\rho

à chaque étage.
Un corollaire utile : quand le goulet est accéléré, il change de place. Le deuxième étage le plus chargé devient le nouveau goulet, et le gain suivant sera plus petit. Une chaîne équilibrée ne s'optimise plus.

La loi de Little hors de l'informatique

La loi de Little ne parle ni de serveurs ni de requêtes : elle parle de choses qui entrent, restent un moment, et sortent. Son domaine est donc bien plus large que les files d'attente.

Une équipe qui traite des demandes en est une. Si vingt demandes sont ouvertes en permanence et que l'équipe en clôt cinq par semaine, le délai moyen de traitement vaut $20 / 5 = 4$ semaines, et aucune bonne volonté ne le raccourcira tant que ces deux nombres ne changent pas.

Le seul levier qui reste quand le débit est fixé

Le délai vaut le nombre de travaux en cours divisé par le débit. Si le débit ne peut pas augmenter, la seule façon de raccourcir le délai est de réduire le nombre de travaux ouverts simultanément.
C'est le fondement des méthodes qui plafonnent le travail en cours. Elles ne rendent personne plus rapide : elles empêchent la file de grossir, et la loi de Little fait le reste. Commencer moins de choses à la fois est le seul moyen de les finir plus vite.

Ce que le modèle ne dit pas

Trois limites à écrire avant de conclure

Les moyennes cachent les queues. Un temps de réponse moyen de 500 millisecondes est compatible avec un centile 99 à cinq secondes. C'est ce centile que l'utilisateur ressent, et le modèle M/M/1 le donne aussi, mais il ne se lit pas sur la moyenne.
Les arrivées sont rarement sans mémoire. Un trafic réel arrive en rafales, ce qui allonge les files par rapport au modèle. Les chiffres calculés ici sont donc des minorants de l'attente réelle.
Le service n'est pas toujours indépendant de la charge. Un serveur saturé devient souvent plus lent qu'à vide, par effet de cache ou de contention. Le modèle suppose

\mu

constant, et la réalité le dégrade au pire moment.

Ces trois limites vont toutes dans le même sens : elles rendent la situation réelle pire que ce que le modèle annonce. C'est ce qui le rend utilisable malgré ses hypothèses : un dimensionnement qui ne tient pas dans le modèle ne tiendra certainement pas en production.

À calculer soi-même

Trois formules et une division suffisent à dimensionner un service. Les poser une fois montre à quel point la marge de sécurité usuelle est mince.

Dimensionner un service

1.
Un serveur traite au plus 10 requêtes par seconde et en reçoit 8. Quel est son taux d'occupation ?
2.
Combien de requêtes se trouvent en moyenne dans le système, celle en cours comprise ?
3.
Quel est le temps de réponse moyen, en millisecondes ?
4.
Le trafic monte à 9 requêtes par seconde. Que devient la longueur moyenne de la file ?
5.
Par quel facteur le temps de réponse a-t-il été multiplié entre 8 et 9 requêtes par seconde ?
6.
Pour garantir un temps de réponse sous 200 millisecondes avec ce même serveur, quel trafic maximal, en requêtes par seconde, peut-on accepter ?
7.
Deux serveurs à 10 requêtes par seconde reçoivent 16 requêtes par seconde. Quel est leur taux d'occupation ?
8.
Le temps de réponse d'un serveur unique suit une loi exponentielle. Combien de fois la moyenne vaut le 99e centile ?
9.
Avec une moyenne de 500 millisecondes, combien vaut ce 99e centile, en millisecondes ?
10.
Rendre le service parfaitement régulier fait passer le coefficient de variation de 1 à 0. Par quel facteur l'attente en file est-elle divisée ?
11.
Des bus passent toutes les 10 minutes en moyenne, à des instants irréguliers. Combien de minutes une personne arrivant sans horaire attend-elle en moyenne ?
12.
Une équipe garde 20 demandes ouvertes en permanence et en clôt 5 par semaine. Quel est le délai moyen de traitement, en semaines ?

La dernière réponse est celle qui dérange. Pour tenir 200 millisecondes, ce serveur ne peut accepter que la moitié de sa capacité. Les cinq requêtes par seconde restantes ne sont pas du gaspillage : elles sont ce qui paie le temps de réponse, et les retirer du dimensionnement revient à promettre une latence qu'on ne tiendra pas.

Où la démarche dérape

Un raisonnement de dimensionnement parfaitement proportionnel, sur une grandeur qui ne l'est pas.

Une capacité qu'on croit proportionnelle

Une seule étape est fausse. Désigner laquelle.

Un serveur traite au plus 10 requêtes par seconde. Il en reçoit $x$ , et l'on cherche le nombre moyen de requêtes présentes dans le système.

Vérification

Vérification rapideon peut se reprendre

1.Que se passe-t-il quand le taux d'occupation atteint 1 ?

2.La loi de Little suppose…

3.Deux serveurs identiques traitent le même trafic total. Quelle organisation donne la plus courte attente ?

4.Un modèle M/M/1 annonce un temps de réponse moyen de 500 millisecondes. Que peut-on en conclure sur l'expérience réelle des utilisateurs ?

Exercices type

Un service reçoit 120 requêtes par minute et en traite au plus 150. Quel est son taux d'occupation, et que vaut sa file ?

Les deux rythmes sont dans la même unité, donc $\rho = 120/150 = 0{,}8$ .

La file vaut $L = 0{,}8 / 0{,}2 = 4$ requêtes en moyenne, et le temps de réponse $W = 1/(150 - 120) = 1/30$ minute, soit 2 secondes.

Le contrôle par la loi de Little confirme : $L = \lambda W = 120 \times 1/30 = 4$ .

Une file compte en moyenne 15 clients et le débit est de 3 clients par minute. Combien de temps un client passe-t-il dans le système ?

La loi de Little se lit dans le sens qui arrange : $W = L / \lambda = 15 / 3 = 5$ minutes.

C'est l'usage le plus fréquent de cette loi. Compter les clients présents et mesurer le débit est facile ; chronométrer chaque client individuellement ne l'est pas, et n'est pas nécessaire.

Pourquoi un serveur à 95 % d'occupation est-il presque toujours un mauvais réglage ?

Parce que la file y vaut 19 demandes et le temps de réponse 20 fois le temps de service. Surtout, la dérivée est telle qu'un point d'occupation de plus double presque l'attente : le système n'a plus aucune marge devant une variation de trafic, même modeste.

Un pic de 5 % sur un serveur à 50 % d'occupation est imperceptible. Le même pic sur un serveur à 95 % le fait basculer au-delà de la stabilité, et la file ne se résorbe qu'une fois le pic passé, avec du retard.

Un serveur deux fois plus rapide, ou deux serveurs partageant une file : que choisir ?

Sur le papier, le serveur deux fois plus rapide donne une attente légèrement plus courte, parce qu'une demande longue n'y bloque personne derrière elle aussi longtemps.

En pratique, deux serveurs l'emportent souvent pour une raison que le modèle ignore : ils survivent à la panne de l'un des deux. Le choix se fait donc entre une latence un peu meilleure et une disponibilité bien meilleure, et c'est rarement la latence qui gagne.

Le trafic double. De combien faut-il augmenter la capacité pour garder le même temps de réponse ?

Le temps de réponse vaut $1/(\mu - \lambda)$ . Le garder constant impose de garder l'écart $\mu - \lambda$ constant, donc d'augmenter $\mu$ de la même quantité que $\lambda$ , et non de le doubler.

Si $\mu = 10$ et $\lambda$ passe de 5 à 10, il faut $\mu = 15$  : la capacité augmente de 50 % quand le trafic a doublé. C'est le seul endroit du chapitre où la non-linéarité joue en faveur de celui qui dimensionne.

La méthode

Écrire les deux rythmes dans la même unité, arrivées et service. C'est là que se logent les erreurs d'un facteur soixante.
Calculer le taux d'occupation en premier, et vérifier qu'il est strictement inférieur à 1. S'il ne l'est pas, aucun autre calcul n'a de sens.
Déduire la file et le temps de réponse par les deux formules, ou par la loi de Little quand l'une des trois quantités est mesurée.
Regarder la dérivée, pas seulement la valeur. Un taux d'occupation acceptable aujourd'hui ne dit rien de ce qu'il devient sous un pic de 10 %.
Annoncer un centile, jamais une moyenne, quand il s'agit d'un engagement de service. Sur un serveur unique, le centile 99 vaut 4,6 fois la moyenne.
Regarder la variabilité autant que la charge. Régulariser le service divise l'attente par deux, ce qu'aucun serveur supplémentaire ne fait à ce prix.
Sur une chaîne, chercher le goulet avant d'optimiser, en comparant les taux d'occupation de chaque étage. Accélérer ailleurs ne change rien au débit.
Conclure en français, en disant quel trafic le dimensionnement accepte et à partir d'où il cesse de tenir.

Synthèse

Une file se décrit par trois ingrédients : le rythme d'arrivée $\lambda$ , le rythme de service $\mu$ , et la discipline.
Le taux d'occupation $\rho = \lambda / \mu$ est la fraction du temps où le serveur travaille. Le système n'est stable que si $\rho < 1$ .
La loi de Little, $L = \lambda W$ , ne suppose presque rien et sert à déduire la quantité qu'on ne sait pas mesurer.
Pour un serveur unique, $L = \dfrac{\rho}{1-\rho}$ et $W = \dfrac{1}{\mu - \lambda}$ .
L'attente n'est pas proportionnelle à la charge : elle explose près de la saturation, et le passage de 0,5 à 0,9 d'occupation multiplie la file par neuf.
Une file unique partagée par plusieurs serveurs bat plusieurs files séparées, parce qu'aucun serveur n'y reste inoccupé pendant que quelqu'un attend.
Avec $c$ serveurs derrière une file commune, $\rho = \lambda / (c\mu)$ , et la probabilité d'attendre est donnée par la formule d'Erlang C. À taux d'occupation égal, tripler le nombre de serveurs divise l'attente par quatre.
Un gros serveur bat plusieurs petits sur le temps total, et perd sur l'attente en file : la réponse dépend de ce qu'on mesure.
Le temps de séjour suit une loi exponentielle, donc le 99^e centile vaut 4,6 fois la moyenne. Un engagement s'écrit sur un centile.
La variabilité pèse autant que la charge : un service régulier divise l'attente par deux, un service deux fois plus variable la multiplie par 2,5.
La discipline ne change ni la longueur moyenne ni l'attente moyenne, tant qu'elle ne regarde pas la durée du service. Elle change seulement qui attend.
Le paradoxe de l'inspection : l'intervalle qui contient un instant pris au hasard est en moyenne deux fois plus long que l'intervalle moyen.
Sur une chaîne de files, le débit est celui du goulet, et la loi de Little s'applique à l'ensemble comme à chaque étage.
La loi de Little vaut hors de l'informatique : réduire le travail en cours est le seul levier quand le débit est fixé.
Le modèle donne des minorants : rafales et ralentissement sous charge rendent la réalité pire.

Et ensuite

Le taux d'occupation et le temps de réponse sont des métriques, et une métrique se surveille. Superviser un système montre comment poser un seuil sur ces mesures sans noyer l'équipe sous les fausses alertes, et Complexité algorithmique explique ce qui fixe le rythme de service $\mu$ d'un traitement donné.