Performances et scalabilité : latence, débit, percentiles et charge

Deux questions différentes : à quelle vitesse, et combien

Les performances sont la qualité que l’on cite en premier et que l’on spécifie le plus mal. Elles recouvrent deux questions différentes. La latence demande combien de temps prend une unité de travail : combien de millisecondes s’écoulent entre le moment où l’on touche « Payer » et celui où l’on voit « Paiement accepté ». Le débit demande quelle quantité de travail le système accomplit par unité de temps : 1200 paiements par seconde, 40 000 commandes par heure. Les deux sont liés mais pas interchangeables. Un autocar qui transporte 50 personnes de Londres à Oxford en 100 minutes a une moins bonne latence et un bien meilleur débit qu’une voiture de sport qui transporte deux personnes en 60 minutes.

Dans le logiciel, la même tension apparaît partout. Regrouper les écritures en base de données par lots améliore le débit, mais fait attendre chaque écriture individuelle jusqu’à son lot. Ajouter un cache améliore les deux pour les lectures répétées, mais ne fait rien pour la première. Une bonne exigence de performances précise donc la question qu’elle traite, et énonce généralement les deux : « à 1200 paiements par seconde (débit), 99 % aboutissent en moins de 800 ms (latence) ». L’ISO/IEC 25010 les range sous l’efficacité des performances, en tant que comportement temporel, utilisation des ressources et capacité (section 2.2).

Temps de réponse = temps de service + temps d’attente

Quand vous mesurez la latence du côté du client, vous obtenez le temps de réponse : tout ce qui s’est passé entre l’envoi de la requête et la réception de la réponse. Il est utile de le décomposer. Le temps de service est le temps qu’une ressource passe réellement à travailler sur votre requête : l’analyser, exécuter la requête en base, produire le résultat. Le temps d’attente est le temps que votre requête passe dans une file parce que la ressource est occupée par celle de quelqu’un d’autre. Le temps de transfert réseau s’ajoute par-dessus, dans les deux sens.

La distinction compte, car les deux parties réagissent à des remèdes différents. Le temps de service diminue quand vous rendez le travail lui-même moins coûteux : un meilleur index, une charge utile plus petite, un algorithme plus rapide. Le temps d’attente diminue quand vous ajoutez de la capacité ou réduisez la charge, et il est souvent bien plus long que le temps de service quand un système est chargé. Bien des enquêtes sur une « base de données lente » se terminent par la découverte que chaque requête prend 5 ms mais attend 300 ms une connexion libre dans le pool.

Percentiles : pourquoi les moyennes trompent

Les temps de réponse ne se résument jamais à un seul nombre ; ils forment une distribution, et celle-ci est presque toujours asymétrique. La plupart des requêtes sont rapides, et une minorité est lente parce qu’elle tombe sur un cache froid, une pause du ramasse-miettes, un verrou, une nouvelle tentative ou un voisin surchargé. La moyenne arithmétique mélange les deux groupes en un chiffre qui ne décrit personne. Les professionnels utilisent plutôt des percentiles. Le 50e percentile (p50, la médiane) est la valeur que bat la moitié des requêtes ; p95 est la valeur que battent 95 % des requêtes ; p99 et p99.9 décrivent les 1 % et 0,1 % les plus lents.

L’extrémité lente de la distribution s’appelle la queue (tail), et elle compte plus qu’il n’y paraît. Les utilisateurs situés dans la queue sont souvent vos meilleurs clients : ceux qui ont les plus gros paniers, les historiques les plus longs et le plus de données. Un utilisateur qui charge 40 ressources pour afficher une page subit la plus lente de ces 40, pas la moyenne. Et la probabilité qu’une page de 40 ressources tombe sur au moins une requête au niveau du p99 est de 1 − 0,99⁴⁰ ≈ 33 % : un événement « rare » à 1 % touche un tiers des affichages de pages.

# Why the mean misleads: 1,000 response times from one minute of traffic
import statistics

times_ms = [80] * 900 + [150] * 80 + [1200] * 15 + [4000] * 5

mean = statistics.mean(times_ms)
cuts = statistics.quantiles(times_ms, n=1000, method="inclusive")
p50, p95, p99, p999 = cuts[499], cuts[949], cuts[989], cuts[998]
print(f"mean {mean:.0f} ms, p50 {p50:.0f}, p95 {p95:.0f}, p99 {p99:.0f}, p99.9 {p999:.0f}")
# mean 122 ms, p50 80, p95 150, p99 1200, p99.9 4000

La latence de queue à grande échelle

La queue devient l’événement principal dans les grands systèmes qui recourent au fan-out (diffusion en éventail), où une requête d’utilisateur est divisée en de nombreuses requêtes parallèles vers d’autres serveurs et où la réponse doit les attendre toutes. Un moteur de recherche, un fil d’actualité social ou une page de recommandations peut consulter des dizaines ou des centaines de shards back-end pour chaque requête. Jeffrey Dean et Luiz André Barroso, de Google, ont analysé ce phénomène dans The Tail at Scale (Communications of the ACM, 2013).

Leur illustration est simple. Supposons que chaque serveur réponde généralement en 10 ms, mais mette 1 seconde pour une requête sur 100. Une requête d’utilisateur qui attend un seul serveur est lente 1 % du temps. Une requête d’utilisateur qui attend 100 serveurs de ce type est lente dès que l’un d’eux est lent : 1 − 0,99¹⁰⁰ ≈ 63 % du temps. Un événement rare sur un serveur devient le cas courant pour l’utilisateur. Dean et Barroso rapportent des mesures d’un service Google dans lequel la latence au 99e percentile pour une seule requête feuille était de 10 ms, mais le 99e percentile de l’attente de toutes les requêtes feuilles était de 140 ms.

Comme on ne peut pas éliminer toutes les sources de variabilité (matériel partagé, tâches d’arrière-plan, ramasse-miettes, files réseau), ils plaident pour des conceptions tolérantes à la queue, de même que les conceptions tolérantes aux pannes acceptent que le matériel tombe en panne. Leurs techniques comprennent les requêtes de couverture (hedged requests : envoyer une deuxième copie à une autre réplique si la première n’a pas répondu dans, disons, le temps du 95e percentile, et utiliser celle qui revient en premier), les requêtes liées (tied requests) qui s’annulent l’une l’autre, des partitions plus fines qui peuvent être rééquilibrées, l’exclusion temporaire des machines lentes, et le renvoi d’un résultat suffisamment bon quand la plupart des shards, mais pas tous, ont répondu. Dans un banc d’essai qu’ils décrivent, déclencher la couverture après 10 ms a fait passer la latence au 99,9e percentile de 1800 ms à 74 ms, en n’envoyant qu’environ 2 % de requêtes en plus.

La loi de Little : combien de requêtes sont en cours

La loi de Little, démontrée par John Little en 1961, est la formule la plus utile en planification de la capacité. Pour tout système stable, le nombre moyen d’éléments qu’il contient (L) est égal au taux d’arrivée moyen (λ, lambda) multiplié par le temps moyen que chaque élément passe à l’intérieur (W) : L = λ × W. Elle est vraie quels que soient le profil des arrivées ou l’ordre de service, à condition que le système soit stable (en moyenne, autant d’éléments sortent qu’il en arrive) et que vous utilisiez des unités cohérentes.

Pour un logiciel, L est le nombre de requêtes en cours simultanément (la concurrence), λ est le débit de requêtes et W est le temps de réponse. Si un service reçoit 200 requêtes par seconde et que chacune y passe 0,25 seconde, alors en moyenne 200 × 0,25 = 50 requêtes sont en cours à tout instant. Ce nombre détermine les pools de threads, les pools de connexions, la mémoire et le nombre de licences. La loi fonctionne aussi à rebours : si vous pouvez traiter au plus 50 requêtes à la fois et que chacune prend 0,25 s, vous ne pouvez pas soutenir plus de 50 ÷ 0,25 = 200 requêtes par seconde.

Taux d’utilisation et files d’attente : pourquoi les systèmes s’effondrent brutalement

Le taux d’utilisation (ρ, rho) est la fraction du temps pendant laquelle une ressource est occupée. Un serveur qui reçoit 40 requêtes par seconde, nécessitant chacune 20 ms de service, est occupé 40 × 0,020 = 0,8 du temps : il est utilisé à 80 %. L’intuition suggère qu’une ressource occupée à 80 % ne devrait être qu’un peu plus lente qu’une ressource occupée à 50 %. La théorie des files d’attente dit le contraire, car les requêtes n’arrivent pas de façon régulière ; elles se regroupent, et quand elles se regroupent, les dernières attendent.

Le modèle le plus simple est la file M/M/1 : arrivées aléatoires, temps de service aléatoires et un seul serveur. Son temps de réponse moyen est W = S ÷ (1 − ρ), où S est le temps de service moyen. À 50 % d’utilisation, W = 2S. À 80 %, W = 5S. À 90 %, W = 10S. À 99 %, W = 100S. Le dénominateur tend vers zéro à mesure que le taux d’utilisation approche 100 %, si bien que le temps de réponse augmente sans limite. Les systèmes réels ne sont pas exactement des M/M/1, et les pools multiserveurs se comportent mieux au même taux d’utilisation, mais la forme est universelle : plate, puis un coude, puis une falaise.

Les leçons pratiques sont directes. Ne prévoyez pas de faire tourner des ressources critiques à près de 100 % d’occupation ; gardez une marge pour que les rafales ne vous fassent pas passer le coude. Surveillez ensemble le taux d’utilisation et la longueur des files (la méthode USE de Brendan Gregg vérifie l’utilisation, la saturation et les erreurs de chaque ressource). Et n’oubliez pas que la falaise rend les petits changements dangereux : à 90 % d’utilisation, une hausse du trafic d’environ 6 % seulement vous amène à 95 % et double le temps de réponse moyen. Le chapitre 9 traite des files d’attente, de la back pressure et de la planification de la capacité dans Asynchronisme, files d’attente et back pressure.

Scalabilité : charge, élasticité, scalabilité verticale et horizontale

La scalabilité est la capacité à absorber plus de charge en ajoutant des ressources, idéalement avec une capacité qui croît proportionnellement et sans refonte. Elle n’a de sens qu’une fois que l’on a précisé ce qu’est la « charge ». Les paramètres de charge diffèrent d’un système à l’autre : requêtes par seconde pour une API, connexions simultanées pour un service de messagerie instantanée, ratio lectures/écritures pour un réseau social, volume de données pour une plateforme d’analytique, ou nombre d’abonnés du compte le plus suivi pour un fil d’actualité. Un scénario de scalabilité nomme le paramètre de charge, la croissance et la réponse qui doit être préservée : « quand les commandes quotidiennes passent de 50 000 à 500 000, la latence p95 du paiement reste inférieure à 1,5 s grâce à l’ajout d’instances, avec un coût par commande au plus 20 % plus élevé ».

L’élasticité ajoute le temps : la capacité à ajouter et retirer de la capacité automatiquement à mesure que la charge monte et descend, pour qu’un site de billetterie puisse grandir pour une mise en vente et rétrécir ensuite. C’est une grande partie de l’argument économique en faveur des plateformes cloud. Il existe deux façons fondamentales d’ajouter de la capacité. La scalabilité verticale (scaling up) donne à une machine plus de CPU, de mémoire ou un stockage plus rapide ; elle est simple, ne demande aucune modification du logiciel, et se heurte à des limites strictes et à des prix croissants. La scalabilité horizontale (scaling out) ajoute des machines et répartit le travail ; elle n’a pas de plafond fixe, mais exige que le logiciel soit conçu pour cela, avec des instances sans état, de l’équilibrage de charge et des données partitionnées. Le chapitre 9 traite des stratégies en détail dans Stratégies de passage à l’échelle : verticale, horizontale et cube de scalabilité.

La loi d’Amdahl : la limite du parallélisme

Ajouter des processeurs ou des nœuds n’aide que pour le travail qui peut se faire en parallèle. La loi d’Amdahl, tirée de l’article de Gene Amdahl de 1967 sur les limites du calcul parallèle, exprime cette idée. Si une fraction s du travail est séquentielle (elle doit se faire une étape après l’autre) et que le reste, 1 − s, peut être réparti parfaitement sur N processeurs, la meilleure accélération possible est accélération(N) = 1 ÷ (s + (1 − s) ÷ N). Quand N croît sans limite, l’accélération tend vers 1 ÷ s. Avec 10 % de travail séquentiel, aucun nombre de processeurs ne peut rendre la tâche plus de dix fois plus rapide.

La loi universelle de scalabilité

La loi d’Amdahl suppose que des processeurs supplémentaires n’aggravent jamais les choses ; l’accélération se contente de plafonner. Les systèmes distribués réels, eux, se dégradent souvent : au-delà d’un certain point, ajouter des nœuds réduit le débit. La loi universelle de scalabilité (USL) de Neil Gunther modélise ce phénomène avec deux pénalités. La contention (α, alpha) est le coût de l’attente pour accéder aux ressources partagées, le même effet que la fraction séquentielle d’Amdahl. La cohérence (β, bêta) est le coût du maintien de la cohérence des données entre les nœuds : chaque nœud doit échanger des informations avec tous les autres, si bien que ce coût croît à peu près comme le carré du nombre de nœuds.

La capacité relative est C(N) = N ÷ (1 + α(N − 1) + βN(N − 1)). Avec β = 0, elle se ramène à la loi d’Amdahl. Avec tout β supérieur à zéro, la capacité atteint un pic vers N = √((1 − α) ÷ β), puis diminue. Pour α = 0,03 et β = 0,002, le pic se situe vers √(0,97 ÷ 0,002) ≈ 22 nœuds, pour une capacité d’environ 8,6 fois celle d’un nœud ; à 32 nœuds, la capacité est retombée à environ 8,2. Gunther décrit le modèle dans Guerrilla Capacity Planning (2007). Son intérêt pratique est que α et β peuvent être ajustés à partir d’une poignée de mesures de tests de charge, ce qui permet de prévoir à quel point le passage à l’échelle cessera d’être rentable avant d’acheter le matériel.

Tactiques de performances : vue d’ensemble

Bass, Clements et Kazman regroupent les tactiques de performances en deux familles. La première consiste à maîtriser la demande de ressources : réduire la quantité de travail qui arrive ou le coût de chaque unité. La seconde consiste à gérer les ressources : faire travailler davantage les ressources disponibles ou en ajouter. La plupart des conceptions réelles combinent plusieurs tactiques ; chacune a aussi des coûts ailleurs, ce qui explique qu’il s’agisse de décisions architecturales.