Files d'attente et dimensionnement

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.

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 » a le sens du chapitre précédent : le temps qui reste avant la prochaine arrivée ne dépend pas du temps déjà écoulé depuis la dernière. L'intervalle entre deux arrivées suit alors la loi exponentielle de paramètre $\lambda$, de moyenne $1/\lambda$, et le nombre d'arrivées pendant une durée $t$ suit la loi de Poisson de paramètre $\lambda t$ du chapitre sur le risque. Il en va de même du service : sa durée suit la loi exponentielle de paramètre $\mu$, et ce qu'il reste à servir ne dépend pas de ce qui a déjà été fait.

C'est une bonne description d'un trafic de clients nombreux et indépendants les uns des autres. Des arrivées parfaitement régulières, une toutes les dix secondes, ne le sont pas, même si chaque intervalle ignore ce qui s'est passé avant. Pour le service, c'est une hypothèse forte, que la section sur la variabilité lève.

Le taux d'occupation

C'est aussi le travail apporté par unité de temps : 12 appels par heure, de 4 minutes chacun, font 48 minutes de travail par heure, soit $\rho = 12 \times 4 / 60 = 0{,}8$.

La condition de stabilité mérite d'être lue lentement. Si $\rho > 1$, il arrive en moyenne plus de demandes que le serveur n'en traite : l'écart s'accumule, et la file grandit sans limite. Le cas $\rho = 1$ est plus trompeur, car arrivées et capacité s'y équilibrent en moyenne. Mais un serveur qui chôme pendant un creux perd ce temps pour toujours, et les rafales qui suivent s'ajoutent à la file sans qu'aucune marge ne les résorbe : la file erre de plus en plus loin, et aucune valeur moyenne n'existe. Le chapitre sur le risque comptait les secondes où les arrivées dépassent la capacité ; la file, elle, reporte sur la seconde suivante tout ce qui n'a pas été servi. Dans les deux cas, 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. Un relevé à 100 % sur une minute, comme ceux du chapitre précédent, ne dit pas encore que $\rho \geq 1$ : il faut que la charge y reste en moyenne, et c'est la file qui le dit.
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 le nombre de demandes présentes, le rythme d'arrivée et le temps de séjour, et elle ne suppose presque rien.

Elle se lit : le nombre moyen de présents vaut le nombre d'arrivées par unité de temps multiplié par la durée moyenne du séjour. Un guichet qui reçoit 30 clients par heure, chacun restant en moyenne 12 minutes, soit 0,2 heure, en abrite donc $30 \times 0{,}2 = 6$ à la fois.

La raison tient dans un double comptage. Sur une longue durée d'observation $T$, le tracé du nombre de présents délimite une aire, en demandes-secondes. Comptée instant par instant, cette aire vaut $L \times T$ ; comptée demande par demande, elle vaut le nombre de demandes passées, $\lambda T$, fois le séjour moyen $W$ de chacune. C'est la même aire, d'où $L = \lambda W$.

Rien dans ce raisonnement ne regarde l'ordre de passage, la loi des arrivées ou le nombre de serveurs : la loi 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.

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 : le nombre de présents et le séjour affichés sont mesurés sur ce qui se passe à l'écran, et la valeur théorique s'affiche à côté pour que les deux se rejoignent.

La figure dit ce qu'aucune formule ne fait sentir. Entre 0 et 0,7, le nombre de présents reste sous deux et demi, 2,3 à 0,7, et le système paraît confortable. Entre 0,9 et 0,95, il passe de 9 à 19 : doubler, pour cinq points de charge de plus.

Voici ce que coûtent ces derniers points de charge. C'est le même service de paiement, la même capacité de 10 demandes par seconde, et 9,5 reçues au lieu de 8, quinze points de charge de plus : un jour de soldes, une campagne, un pic de fin de mois.

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.

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 la figure ci-dessous l'affiche pour chaque réglage, sur la ligne « risque d'attendre ». Deux cas suffisent à la main. Avec deux serveurs, elle tient en une ligne, $2\rho^2/(1+\rho)$ ; et quel que soit $c$, l'attente en file moyenne s'en déduit en divisant ce risque par la marge de capacité, $W_q = P_{\text{attendre}}/(c\mu - \lambda)$. Ce qu'elle produit vaut la peine d'être regardé.

Ce tableau ne compare pas encore les deux leviers : il fait grandir le trafic et le nombre de serveurs ensemble, pour isoler l'effet du nombre de serveurs. Les trois lignes ont le même taux d'occupation et des attentes en file dans un rapport de près de quatre, 400 contre 108 millisecondes. 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.

Il se lit aussi entre les deux premières lignes. Deux serveurs ayant chacun sa file et 8 requêtes par seconde, ce sont deux copies de la première ligne : 400 millisecondes d'attente en file. Les mêmes derrière une file commune, c'est la deuxième ligne : 178 millisecondes.

Une file commune, pas une file par serveur. Avec des files séparées, un serveur peut chômer pendant que quelqu'un attend ailleurs, et ce temps perdu ne se rattrape jamais.
Le gain, compté en temps, grandit avec la charge : avec deux serveurs à 10 requêtes par seconde, la file commune fait gagner 67 millisecondes d'attente en file à mi-charge, 222 à 0,8 et près d'une seconde à 0,95. En proportion, il va dans l'autre sens : elle divise l'attente en file par 3 à mi-charge, par 2,25 à 0,8, et par un peu plus de 2 près de la saturation.

La variabilité pèse autant que la charge

Le modèle suppose des services de durée très variable : une loi sans mémoire a un écart-type égal à sa moyenne, comme l'a établi le chapitre sur le risque. 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 :

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 (rien à voir avec le nombre $c$ de serveurs : la formule vaut pour un serveur). Un processus sans mémoire a un coefficient de 1 ; un service parfaitement régulier a un coefficient de 0.

La formule se lit comme un produit de trois facteurs : la charge, $\rho/(1-\rho)$, la variabilité, moyenne des carrés des deux coefficients, et la durée d'un service, $1/\mu$. Avec deux processus sans mémoire, le facteur du milieu vaut 1 et l'on retrouve exactement l'attente en file du modèle M/M/1. Avec des arrivées sans mémoire, elle est même exacte quel que soit le service.

La troisième ligne est la seule approchée : le calcul exact donne 169 millisecondes, et l'ordre de grandeur reste le bon.

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 l'écart-type vaut deux fois la durée 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, réserver une file aux requêtes légères, comme les caisses express d'un supermarché, plafonner la taille d'un lot : toutes ces mesures réduisent $c_s$. Séparer défait pourtant une partie de la mutualisation : le gain sur la variabilité doit la compenser, ce qui est le cas quand les durées diffèrent d'un ordre de grandeur, et pas quand elles se ressemblent.
À $\lambda = 8$, diviser l'attente par deux en accélérant le serveur demanderait de porter $\mu$ de 10 à 11,5 environ : régulariser vaut 15 % de capacité en plus.

La formule se vérifie en quelques lignes de code. Chaque client hérite de ce qui restait à faire au précédent, moins l'intervalle qui les sépare, et son attente ne descend jamais sous zéro : c'est toute la file d'attente, client par client.

Les deux attentes, 389 et 207 millisecondes, tombent près des 400 et 200 du tableau ; l'écart restant tient au hasard des 200 000 clients. Une seule ligne distingue les deux cas, celle qui tire la durée du service. Le max(0.0, …) est celui du débogage de la file qui passe sous zéro, parmi les exercices du chapitre : une file ne met jamais de temps libre en réserve.

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, servi dans l'ordre d'arrivée, le temps $S$ qu'un client passe dans le système, service compris, suit la loi exponentielle du chapitre précédent. Son paramètre n'est pas le rythme d'arrivée $\lambda$, c'est l'écart $\mu - \lambda$ : la moyenne vaut bien $W = 1/(\mu - \lambda)$. La proportion de clients qui restent plus d'un temps $t$ dans le système vaut donc

Le chapitre précédent a établi les quantiles de cette loi : $-\ln(1 - q)$ divisé par son paramètre. Le centile d'ordre $q$, la durée que seule une fraction $1 - q$ des clients dépasse, vaut donc ici

Le centile se calcule en une ligne, sans simulation : la médiane vaut $\ln 2 \approx 0{,}69$ fois la moyenne, le centile 99 vaut $\ln 100 \approx 4{,}6$ fois la moyenne.

Le chapitre précédent trouvait des latences log-normales sur des serveurs réels, et ce modèle annonce une exponentielle. Les deux ne se contredisent pas : toutes deux sont étalées à droite, avec une moyenne au-dessus de la médiane. L'exponentielle est ce que donne un serveur idéal sans mémoire ; la log-normale, ce que donnent des requêtes qui traversent plusieurs couches. Dans les deux cas, la moyenne ne dit pas ce que vit le client malchanceux.

Ce que cela impose à un engagement de service. Un engagement écrit sur la moyenne est presque toujours une erreur : dans ce modèle, il peut être tenu pendant qu'un client sur cent reste dans le système plus de 4,6 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, à 8 demandes par seconde, une capacité de 17 au lieu de 10, 72 % de plus.

La discipline change qui attend, pas combien

La section précédente a montré qu'une moyenne cache une distribution. L'ordre de passage agit exactement là.

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 tient en deux temps. D'abord, tant que la discipline ne laisse jamais un serveur inoccupé devant une file non vide, le serveur travaille exactement aux mêmes instants : l'ordre décide seulement qui il sert, pas combien de travail il abat. Si, de plus, elle ne regarde pas la durée des services, le nombre de présents a la même évolution, donc la même moyenne $L$. Ensuite, la loi de Little, $W = L / \lambda$, donne le même temps moyen.

Ce qui change, et radicalement, c'est la distribution. En premier arrivé premier servi, les attentes sont les moins dispersées, ce qui ne veut pas dire égales : à $\rho = 0{,}8$, un client sur cinq passe sans attendre et un sur dix attend plus d'une seconde. En dernier arrivé premier servi, la plupart passent presque tout de suite, six sur dix en moins de 100 millisecondes, et quelques-uns, arrivés juste avant une rafale, attendent des durées sans commune mesure : le centile 99 de l'attente y est à peu près trois fois celui du premier arrivé premier servi. Même moyenne, expériences opposées.

Les files d'attente humaines

Tout ce qui précède vaut pour des requêtes, des pièces ou des clients : le modèle ne fait pas la différence. Une file humaine en ajoute pourtant une, et elle est décisive. Une requête ne se demande pas si la file d'à côté avance plus vite, ne renonce pas, et ne raconte pas son attente à ses amis. Une personne, si : et une attente mesurée ne compte que ceux qui sont restés.

Le passage du modèle au terrain se fait par un objet très concret : la barrière. Un exploitant de parc, de gare ou de supermarché ne choisit pas une discipline en la décrétant, il la rend physique en posant des barrières, et c'est ce geste qui décide de qui peut doubler qui.

Une file, ou une par guichet

La section sur la mutualisation a montré le résultat par le calcul, entre les deux premières lignes de son tableau : à capacité totale égale, les clients de plusieurs serveurs derrière une seule file attendent moins que ceux du même nombre de serveurs ayant chacun la sienne. La vue de haut le fait subir, sur la même foule, aux mêmes instants.

Les files parallèles perdent sur les deux tableaux, et pour deux raisons différentes : un guichet peut chômer pendant qu'une autre file attend, et une file courte peut cacher un service long.

Ce que la file unique achète, et ce qu'elle coûte. Elle supprime le dépassement : l'ordre d'arrivée est l'ordre de service, et personne ne peut plus se tromper de file. Elle mutualise : aucun guichet ne chôme devant une file non vide.
Elle coûte un cheminement plus long, et elle rend la file visible d'un seul tenant : une file unique de quarante personnes paraît plus longue que trois files de treize, alors qu'elle s'écoule plus vite.

Le serpentin ne change pas la file, il change ce qu'on en voit

Plier une file en couloirs parallèles ne modifie ni l'ordre de passage, ni l'attente : c'est la même file, repliée. Ce que le pliage change est ailleurs.

Ce que l'attente fait ressentir

Le temps d'attente ressenti n'est pas le temps d'attente mesuré, et l'écart n'a rien d'aléatoire. David Maister l'a formulé en 1985 en huit propositions, avancées comme des hypothèses et en partie confirmées depuis ; les plus utiles ici tiennent en quatre lignes.

Quatre effets, et ce qu'ils impliquent pour l'exploitant.

Une attente inoccupée paraît plus longue qu'une attente occupée. D'où les files thématisées, les écrans, les pré-spectacles : ils ne raccourcissent rien, ils remplissent.
Une attente de durée inconnue paraît plus longue qu'une attente annoncée. D'où les temps affichés à l'entrée des files, souvent majorés : les relevés indépendants des grands parcs trouvent des attentes réelles nettement plus courtes que l'affichage, et arriver plus tôt que promis se ressent comme un gain.
Une attente inexpliquée paraît plus longue qu'une attente justifiée. D'où l'annonce du motif d'un retard, qui ne change rien au retard.
Une attente injuste paraît plus longue qu'une attente équitable. Richard Larson en a fait en 1987 l'argument central de la conception des files, et c'est celui que les barrières décident.

Le quatrième explique pourquoi la file unique s'est imposée dans les banques, les aéroports et les grands parcs, et pas seulement parce qu'elle raccourcit l'attente moyenne : elle supprime le dépassement, donc le sentiment d'injustice, donc l'attente ressentie. Elle supprime aussi l'anxiété du choix, cette question qui accompagne toute file parallèle : « ai-je pris la bonne ? »

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.

La capacité de la chaîne, le plus grand trafic qu'elle peut absorber, est celle de son étage le plus lent, et d'aucun autre. Accélérer un étage qui n'est pas le goulet ne la relève pas d'une seule requête par seconde : au-delà de cette capacité, l'attente s'accumule devant le goulet, quoi qu'on fasse ailleurs.

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.

Une chaîne sans place pour attendre : monter dans un avion

L'allée d'un avion est une chaîne de files d'un genre particulier : chaque rangée est un étage, et il n'y a aucune place pour attendre entre deux étages. Un passager qui range son bagage ne ralentit pas seulement son étage, il bloque l'allée, donc tous ceux qui sont derrière lui ; un passager déjà assis côté couloir doit se lever pour laisser passer celui du hublot. Dans la simulation ci-dessous, ces deux blocages font toute la durée.

La méthode par blocs de l'arrière vers l'avant, longtemps la plus courante, est l'une des plus lentes, ce qu'une expérience en vraie grandeur a confirmé en 2011 : elle rassemble au même endroit des gens qui rangent tous leur bagage en même temps, c'est le maximum de blocage d'allée. La simulation fait monter les mêmes passagers, avec les mêmes bagages, dans deux ordres d'appel.

Les cinq méthodes, sur la même cabine et les mêmes bagages :

Le hasard bat l'organisation, et ce n'est pas une boutade. Embarquer au hasard est plus rapide que par blocs de l'arrière vers l'avant, parce que le hasard répartit naturellement les passagers le long de l'allée, là où les blocs les concentrent devant un seul étage.
Appeler les hublots avant les couloirs supprime entièrement la seconde cause, les voisins levés. La méthode de Steffen ajoute l'espacement d'une rangée sur deux, ce qui réduit la première à presque rien, 223 blocages d'allée contre 1 754 : elle est la plus rapide des cinq, et de loin.

Le travail en cours : la loi de Little appliquée à une équipe

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 entre le début et la fin d'un travail 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 retiennent les demandes à l'entrée au lieu de les commencer toutes, et la loi de Little fait le reste. Le demandeur, lui, n'attend moins au total que si le débit monte, ce que permet souvent la fin des allers-retours entre tâches.

Le paradoxe de l'inspection : l'attente à l'arrêt de bus

Les bus passent toutes les dix minutes en moyenne, mais complètement au hasard, comme les arrivées sans mémoire de ce chapitre. Une personne qui arrive à l'arrêt sans consulter l'horaire attend en moyenne dix minutes, et non cinq.

L'absence de mémoire du chapitre précédent le dit en une ligne : le temps qui reste avant le prochain bus ne dépend pas du temps écoulé depuis le dernier, il a donc la loi d'un intervalle entier, de moyenne dix minutes.

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. Pour des passages sans mémoire, l'intervalle qui contient l'instant d'arrivée dure en moyenne vingt minutes, deux fois l'intervalle moyen, et l'on en attend en moyenne la moitié : dix minutes. Avec des bus simplement irréguliers, l'effet est plus faible : des intervalles répartis uniformément entre 5 et 15 minutes donnent une attente moyenne d'environ 5,4 minutes. Avec des bus qui arrivent en grappes, il est plus fort.

Où ce biais se rencontre ailleurs. 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é des requêtes en cours, pris à des instants quelconques, surreprésente les requêtes longues, pour la même raison : une requête longue a plus de chances d'être en cours au moment du relevé. Dans les deux cas, le nombre obtenu est juste et ne répond pas à la question posée.
Pour connaître la durée moyenne des requêtes, la loi de Little évite le piège : le nombre de requêtes en cours, lui, est juste à tout instant, et il suffit de le diviser par le débit.

Ce que le modèle ne dit pas

Les trois dernières limites vont dans le même sens : rafales, ralentissement sous charge et pics rendent la situation réelle pire que ce que le modèle annonce. Seuls des arrivées ou un service plus réguliers que le modèle jouent en sa faveur, et la formule de Kingman permet de le chiffrer. C'est ce qui rend le modèle utilisable malgré ses hypothèses : un dimensionnement qui ne tient pas dans le modèle a peu de chances de tenir en production, à moins que le service y soit nettement plus régulier.

Le service de paiement, pour finir

Un jour de soldes, le service reçoit 9,5 demandes par seconde pour une capacité de 10 : 2 secondes de temps de réponse en moyenne, et un centile 99 vers 9 secondes. Régulariser le service ne suffit pas : l'attente en file passerait de 1,9 à 0,95 seconde.

Une machine deux fois plus rapide ramène le temps moyen à 95 millisecondes, et le centile 99 à 440. Deux machines à 10 derrière une file commune donnent 129 millisecondes en moyenne, dont 29 d'attente avant la prise en charge ; et si l'une tombe, l'autre retrouve exactement la situation d'aujourd'hui, $\rho = 0{,}95$, lente mais stable.

Le calcul ne tranche pas seul : la machine rapide gagne sur le temps moyen, les deux machines sur l'attente avant la prise en charge et sur la panne, parce que chacune reste sous 50 % d'occupation. Écrite en français, la conclusion tient en deux phrases. Avec une seule machine, le service tient 8 demandes par seconde sous une demi-seconde en moyenne, et 95 % de ses demandes sous 1,5 seconde ; au-delà, il cesse de tenir. Pour un jour de soldes à 9,5, une deuxième machine derrière une file commune ramène le temps moyen sous 130 millisecondes et survit à une panne ; une machine deux fois plus rapide fait un peu mieux sur la moyenne, mais tombe avec elle.

La méthode

1. Écrire les deux rythmes dans la même unité, arrivées et service. Une durée de service se convertit en rythme par son inverse : 4 minutes par appel font 15 appels par heure. C'est là que se logent les erreurs d'un facteur soixante.
2. 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.
3. Vérifier que les moyennes ont un sens : un trafic à peu près constant, observé assez longtemps. Pendant un pic au-delà de la capacité, compter un réservoir qui se remplit, pas une file moyenne.
4. Déduire les présents 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.
5. Regarder la pente, pas seulement la valeur. Un taux d'occupation acceptable aujourd'hui ne dit rien de ce qu'il devient sous un pic de 10 %.
6. Annoncer un centile, jamais une moyenne, quand il s'agit d'un engagement de service. Dans le modèle à un serveur, le centile 99 vaut 4,6 fois la moyenne ; sur un service réel, il se mesure.
7. 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.
8. 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 à la capacité.
9. Conclure en français, en disant quel trafic le dimensionnement accepte et à partir d'où il cesse de tenir.

Mettre en pratique

Un guichet de préfecture, cette fois : les données de terrain arrivent en durées, et la charge varie dans la journée.

La septième réponse est celle qui dérange : pour tenir 6 minutes, ce guichet ne peut accepter que 20 personnes par heure, les deux tiers de sa capacité. La capacité restante n'est pas du gaspillage, c'est elle qui paie le temps de réponse, et la retirer du dimensionnement revient à promettre une attente qu'on ne tiendra pas.

Le pic dit pourquoi : deux heures à 120 % laissent douze personnes de trop, et la marge ordinaire met près de deux heures et demie à les absorber. Ce que la pointe accumule se paie bien après elle.