Découvrez la démarche d'une étude de performance

Le jour de l’ouverture de la billetterie d’un grand festival de musique rennais, des milliers de personnes se connectent en même temps. Le site va-t-il tenir ? Faut-il un deuxième serveur de base de données, ou plus de mémoire ? Et que veut dire « tenir », au juste : répondre en moins d’une seconde, ne perdre aucune commande, servir 50 achats par seconde ?

Avant de sortir un chronomètre ou une formule, il faut savoir quoi mesurer, pourquoi, et avec quelle technique. C’est l’objet de ce chapitre. Nous suivrons cette billetterie tout au long des six premiers chapitres du cours.

Évaluer les performances, pour quoi faire ?

Évaluer les performances d’un système informatique, c’est quantifier le service qu’il rend : à quelle vitesse, en quelle quantité, avec quelle fiabilité et à quel coût. On le fait rarement par curiosité. Les motivations habituelles sont :

• comparer deux conceptions ou deux produits (tel moteur de base de données ou tel autre) ;
• dimensionner (capacity planning) : combien de serveurs pour absorber le pic de l’ouverture des ventes ?
• régler un système existant (taille d’un cache, nombre de processus) ;
• déboguer une lenteur : quelle ressource freine tout le reste ?
• prévoir : que se passera-t-il si le trafic double l’an prochain ?

Pour en parler précisément, fixons trois mots de vocabulaire.

• La charge (workload) est l’ensemble des demandes adressées au système : ici, des consultations de pages, des ajouts au panier, des paiements. Pour une base de données, ce seraient des requêtes SQL ; pour une grappe de calcul, des tâches.
• Une métrique est un critère chiffré qui dit si le service est bon : le temps de réponse d’un paiement, le nombre de commandes validées par seconde.
• Un facteur est un paramètre que l’on fait varier pendant l’étude (le nombre d’utilisateurs connectés, la taille du cache, le type de disque), et un niveau est une valeur choisie pour ce facteur (100, 1 000 ou 10 000 utilisateurs).

Les métriques de base

Trois métriques reviennent dans presque toutes les études. Retenez-les bien : tout le reste du cours les relie entre elles.

Métrique	Notation	Définition	Unité
Temps de réponse	$R$	durée entre l’envoi d’une requête et la réception de la réponse	s, ms
Débit (throughput)	$X$	nombre de requêtes terminées par unité de temps	req/s
Utilisation	$U$	fraction du temps pendant laquelle une ressource est occupée	sans unité, entre 0 et 1

On y ajoute selon le contexte la fiabilité (probabilité d’erreur, taux de panne), la disponibilité (la fraction du temps où le service fonctionne, $\text{uptime} / (\text{uptime} + \text{downtime})$), et le coût, en euros, en watts ou en émissions de CO2.

Plus c’est haut, mieux c’est ? Pas toujours

Les métriques n’ont pas toutes le même « sens ». On distingue trois classes :

• HB (higher is better) : plus c’est haut, mieux c’est. Le débit, la disponibilité.
• LB (lower is better) : plus c’est bas, mieux c’est. Le temps de réponse, le coût.
• NB (nominal is best) : il existe une valeur idéale intermédiaire. L’utilisation en est l’exemple type : à 5 %, vous payez un serveur qui ne fait rien ; à 99 %, les requêtes font la queue et le temps de réponse explose (vous verrez pourquoi au chapitre 4).

Le débit est HB, le temps de réponse LB. L'utilisation est NB : trop basse, on paie un serveur inutile ; trop haute, les files d'attente dégradent le service.

La moyenne ne suffit pas : les percentiles

Imaginez que le paiement réponde en 200 ms en moyenne. Rassurant ? Pas forcément. Si 98 paiements sur 100 prennent 100 ms et que les 2 autres en prennent 5 secondes, la moyenne vaut $0{,}98 \times 0{,}1 + 0{,}02 \times 5 = 0{,}198$ s. Elle cache complètement les clients qui ont attendu cinq secondes, et qui ont peut-être abandonné leur achat.

C’est pourquoi on décrit un temps de réponse par sa distribution, et en particulier par ses percentiles : le percentile 95 (noté p95) est la valeur sous laquelle se trouvent 95 % des temps observés. La médiane est le p50. Dans l’exemple, le p50 vaut 100 ms mais le p99 vaut 5 s : les deux chiffres ensemble racontent la vraie histoire.

À retenir

Un temps de réponse se résume par plusieurs percentiles (p50, p95, p99), pas par sa seule moyenne. Les objectifs de service sont d’ailleurs souvent écrits ainsi : « 99 % des paiements en moins de 500 ms ».

import statistics

# Temps de réponse (en ms) de 20 paiements relevés sur la billetterie (données inventées)
temps = [95, 102, 98, 110, 101, 97, 120, 99, 103, 5000,
         96, 100, 104, 98, 115, 101, 99, 97, 4800, 102]

centiles = statistics.quantiles(temps, n=100)   # les 99 points de coupure p1 ... p99
print(f"moyenne : {statistics.mean(temps):.0f} ms")
print(f"p50     : {statistics.median(temps):.0f} ms")
print(f"p95     : {centiles[94]:.0f} ms")

Sur ces 20 valeurs, la moyenne (582 ms) ne correspond à aucun paiement réel : ni aux 18 rapides, ni aux 2 très lents. La médiane (101 ms) décrit l’expérience typique, et le p95 (4 990 ms) révèle la queue lente : 10 % des paiements atteignent ou dépassent 4,8 secondes.

La moyenne (582 ms) tombe dans le vide entre les deux groupes ; la médiane décrit le paiement typique et le p95 révèle la queue lente.

Attention

Un percentile élevé demande beaucoup de données. Avec 20 mesures, le p99 n’est pas estimable sérieusement : il faudrait au moins plusieurs centaines d’observations pour qu’une poignée d’entre elles tombent au-delà. Nous y reviendrons au chapitre 10.

La démarche en neuf étapes

Une étude de performance ressemble à une expérience scientifique : on la prépare avant de lancer quoi que ce soit. Voici une démarche classique, appliquée à la billetterie.

1. Fixer les objectifs et délimiter le système. « Le site doit supporter le pic d’ouverture des ventes. » Le système étudié comprend-il le prestataire de paiement externe ? Vous ne le maîtrisez pas : si vous l’excluez, il faudra le remplacer pendant les essais par un bouchon qui imite ses temps de réponse.
2. Lister les services rendus et leurs issues possibles : consulter, réserver, payer ; chaque requête peut réussir, échouer ou expirer.
3. Choisir les métriques : p99 du temps de paiement, nombre de commandes par seconde, taux d’erreur, utilisation de chaque ressource.
4. Lister les paramètres du système (processeurs, disques, taille des caches) et de la charge (nombre d’utilisateurs, proportion de paiements, temps de réflexion entre deux clics).
5. Choisir les facteurs et leurs niveaux parmi ces paramètres : on ne peut pas tout faire varier.
6. Choisir la technique d’évaluation : modèle, simulation ou mesure (section suivante).
7. Choisir la charge : elle doit être représentative. Rejouer une heure calme de novembre ne dit rien du pic d’ouverture.
8. Concevoir les expériences pour obtenir le plus d’information avec le moins d’essais (chapitre 8).
9. Analyser et présenter les résultats en tenant compte de leur variabilité (chapitre 7), puis recommencer si besoin : une étude est souvent itérative.

Les cinq premières étapes se font avant toute mesure ; la flèche de retour rappelle qu'une étude est souvent itérative.

Piège

Le piège le plus courant n’est pas technique : c’est un objectif biaisé. « Montrer que notre nouvelle architecture est la meilleure » conduit, consciemment ou non, à choisir la charge, les métriques et les niveaux qui l’avantagent. Un bon objectif est neutre : « déterminer laquelle des deux architectures tient le pic avec un p99 sous 500 ms ».

Modèle, simulation ou mesure ?

Il existe trois grandes techniques pour obtenir des chiffres. Elles ne s’opposent pas : on les combine, et chacune sert à vérifier les autres.

Technique	Quand l’utiliser	Coût et délai	Précision	Crédibilité
Modélisation analytique	à tout stade, même avant que le système existe	faible, rapide	faible à moyenne (hypothèses simplificatrices)	faible
Simulation	système absent, ou trop coûteux à tester en vrai	moyen	moyenne	moyenne
Mesure	le système existe et on peut y faire des essais	élevé, long	élevée	la plus convaincante

• La modélisation analytique représente le système par des équations : les lois opérationnelles et les files d’attente des chapitres 2 à 5. En quelques minutes, elle dit si l’on est loin ou près de la saturation.
• La simulation reproduit le comportement du système dans un programme, événement par événement (chapitre 6). Elle accepte des hypothèses plus réalistes que les formules, au prix d’un effort de programmation.
• La mesure observe le vrai système sous une charge contrôlée (chapitres 7 à 10). C’est ce qui convainc le mieux un décideur, mais il faut que le système existe, et chaque expérience coûte du temps.

Mais alors, pourquoi ne pas toujours mesurer ? Bonne question ! Parce qu’on ne peut pas mesurer un système qui n’est pas encore acheté, et parce qu’une mesure ne dit que ce qui s’est passé dans la configuration testée. Un modèle, lui, se transpose : une fois calibré sur des mesures, il prédit ce qui arrivera avec deux fois plus d’utilisateurs ou un disque plus rapide.

À retenir

Une règle de prudence : ne faites jamais confiance à un seul type de résultat. Validez la simulation par des mesures ou un modèle simple, et vérifiez que les mesures sont compatibles avec ce que prédisent les lois opérationnelles.

En entretien

« Pour évaluer un système, je fixe d’abord l’objectif et les métriques, en décrivant la latence par ses percentiles. Ensuite, je choisis entre modèle, simulation et mesure selon que le système existe ou non, et je fais en sorte que les méthodes se valident entre elles. »

Les erreurs classiques

La liste des erreurs fréquentes est un bon pense-bête avant de rendre une étude :

• pas d’objectif clair, ou un objectif biaisé ;
• des métriques mal choisies : mesurer ce qui est facile (le temps CPU) plutôt que ce qui compte (le temps de réponse perçu) ;
• une charge non représentative ;
• choisir la technique qu’on maîtrise plutôt que celle qui convient ;
• ignorer la variabilité : une seule exécution, une moyenne sans dispersion ;
• oublier des paramètres importants, ou les faire varier un par un en ratant leurs interactions (chapitre 8) ;
• une présentation trompeuse : échelles tronquées, ratios choisis pour arranger (chapitre 9).

En résumé

• Évaluer les performances, c’est quantifier le service rendu, pour comparer, dimensionner, régler, déboguer ou prévoir.
• La charge est l’ensemble des demandes ; un facteur est un paramètre que l’on fait varier, un niveau une valeur de ce facteur.
• Les trois métriques de base sont le temps de réponse $R$, le débit $X$ et l’utilisation $U$. Elles sont LB, HB et NB respectivement.
• Un temps de réponse se décrit par ses percentiles (p50, p95, p99), car la moyenne masque les requêtes lentes.
• La démarche suit neuf étapes, de l’objectif à la présentation, en commençant par un objectif neutre.
• Les trois techniques, modèle, simulation et mesure, se complètent et se valident entre elles.

Exercices

Exercice · Classer des métriques

facile

Pour chaque métrique, dites si elle est HB, LB ou NB :

1. le nombre d’images classées par seconde par un service d’inférence ;
2. le p99 du temps de chargement d’une page ;
3. le taux d’occupation d’un processeur de serveur ;
4. la consommation électrique d’une grappe de calcul ;
5. la disponibilité mensuelle d’un site.

Voir la solution

1. HB : c’est un débit, on en veut le plus possible.
2. LB : un temps de réponse, on le veut le plus bas possible.
3. NB : trop bas, on paie une machine inutile ; trop haut, les requêtes attendent. On vise typiquement une zone intermédiaire.
4. LB : un coût.
5. HB : plus le service est disponible, mieux c’est.

Exercice · Moyenne et percentiles

moyen

Sur 1 000 recherches de concerts, 960 répondent en 80 ms, 32 en 400 ms et 8 en 3 s.

1. Calculez le temps de réponse moyen.
2. Donnez la médiane, le p95 et le p99.
3. L’objectif est « 99 % des recherches en moins de 500 ms ». Est-il respecté ?

Voir la solution

1. Moyenne : $(960 \times 0{,}08 + 32 \times 0{,}4 + 8 \times 3) / 1\,000 = (76{,}8 + 12{,}8 + 24) / 1\,000 = 0{,}1136$ s, soit environ 114 ms.
2. Rangeons les temps : les rangs 1 à 960 valent 80 ms, les rangs 961 à 992 valent 400 ms, les rangs 993 à 1 000 valent 3 s. La médiane (rang 500) vaut 80 ms, le p95 (rang 950) vaut encore 80 ms, et le p99 (rang 990) vaut 400 ms.
3. 992 recherches sur 1 000, soit 99,2 %, répondent en moins de 500 ms : l’objectif est respecté, mais de peu. Trois recherches lentes de plus le feraient échouer. Remarquez que la moyenne, 114 ms, ne permettait pas du tout de répondre à cette question.

En code

Python

import numpy as np

# 960 recherches à 80 ms, 32 à 400 ms, 8 à 3 000 ms
temps = np.repeat([80, 400, 3000], [960, 32, 8])

print(temps.mean())                          # 113.6 ms
print(np.percentile(temps, [50, 95, 99]))    # [ 80.  80. 400.]
part_rapide = np.mean(temps < 500)           # fraction sous 500 ms
print(part_rapide, part_rapide >= 0.99)      # 0.992 True : objectif respecté

R

# 960 recherches à 80 ms, 32 à 400 ms, 8 à 3 000 ms
temps <- rep(c(80, 400, 3000), times = c(960, 32, 8))

mean(temps)                                  # 113.6 ms
quantile(temps, c(0.50, 0.95, 0.99))         # 80  80  400
part_rapide <- mean(temps < 500)             # fraction sous 500 ms
c(part_rapide, part_rapide >= 0.99)          # 0.992  1 (TRUE) : objectif respecté

Exercice · Choisir une technique

moyen

Pour chaque situation, proposez la technique d’évaluation la plus adaptée et justifiez.

1. Un opérateur hésite entre deux baies de stockage qu’il n’a pas encore achetées.
2. La billetterie existe ; on veut savoir pourquoi le paiement est lent depuis la dernière mise à jour.
3. Une équipe conçoit un nouvel algorithme d’ordonnancement pour un réseau de capteurs de 10 000 nœuds.

Voir la solution

1. Modélisation analytique, à partir des caractéristiques annoncées (débit et temps d’accès des disques) et de la charge actuelle mesurée. Si l’enjeu financier est important, on complète par une mesure sur une baie prêtée par le fournisseur, avec une charge représentative.
2. Mesure : le système existe, et on cherche une cause précise. On profile le paiement, on compare les versions avant et après la mise à jour sur la même charge (chapitre 7).
3. Simulation : le système n’existe pas, et 10 000 nœuds physiques coûteraient trop cher à déployer. Un modèle analytique simple peut servir en amont, pour vérifier que la simulation donne des ordres de grandeur cohérents.