- Description
- Tableau de bord d'automobile de nuit : compte-tours et compteur de vitesse aux aiguilles rouges.
- Source
- Spacekid · page d’origine
- Licence
- CC0 Domaine public
Performance et scalabilité
Ce thème mesure la capacité du logiciel à tenir ses temps de réponse et ses temps de traitement quand le volume ou la charge augmentent, et la capacité de l'équipe à le prouver avant la…
En bref
Ce thème mesure la capacité du logiciel à tenir ses temps de réponse et ses temps de traitement quand le volume ou la charge augmentent, et la capacité de l'équipe à le prouver avant la production. Les promesses s'expriment en percentiles de latence, en durée de traitement et en marge de croissance. La performance spécifique aux rapports et au modèle sémantique est traitée dans BI 03.
Niveau : 🟢→🔴 · Code thème : PRF (matrice DL)
Pourquoi ce thème#
La performance est une dette qui se révèle d'un coup : tout marche avec le jeu de données de recette, puis le volume réel multiplie la durée par dix ou par cent, parce qu'un algorithme est quadratique, qu'un index manque ou qu'un plan d'exécution a changé. La loi de Little (le nombre moyen d'éléments en cours dans un système égale le débit multiplié par le temps moyen de séjour) rappelle qu'un système saturé voit ses délais exploser non linéairement : à 90 % d'utilisation, la file d'attente est déjà longue.
Deux règles d'or : mesurer avant d'optimiser (l'intuition se trompe sur l'emplacement des goulots), et raisonner en percentiles plutôt qu'en moyennes (un p50 à 200 ms avec un p99 à 8 s est un mauvais service pour 1 requête sur 100). Pour un traitement de données par lots, l'équivalent est la fenêtre de traitement : durée totale, marge avant l'heure critique, croissance par rapport au volume.
Variabilité de la mesure : sur des plateformes mutualisées (pool élastique, capacité partagée), le temps écoulé peut varier du simple au double d'une exécution à l'autre ; mesurer en consommation de CPU et en lectures logiques, plusieurs fois et en alternance, est plus fiable que de comparer des durées uniques.
Ce que mesure le thème#
- Axe : de « on découvre les lenteurs en production » à « la performance est un critère de conception testé, budgété et surveillé ».
- Indicateurs clés : latence p95/p99 des opérations critiques ; durée de la fenêtre de traitement et marge ; élasticité (coût et temps pour absorber ×2 de volume) ; part des régressions de performance détectées avant production.
- Unité : ms/s ; minutes ; ratio ; %.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Subie | La performance est connue quand elle pose problème. | Aucune mesure ; plaintes |
| 2 | Mesurée | On sait combien prend chaque opération critique aujourd'hui. | Mesures ponctuelles ; référence chiffrée |
| 3 | Budgétée | Chaque opération critique a un budget, et un dépassement est vu avant la livraison. | Budgets ; test de non-régression ; p95 documenté |
| 4 | Prévue | On sait ce que donnera un volume ×3 ou ×10, et le coût pour l'absorber. | Tests de charge sur volumes cibles ; marge ≥ 50 % |
| 5 | Élastique | Le système s'adapte à la charge sans intervention, avec un coût proportionnel à l'usage. | Mise à l'échelle automatique ; coût par unité de service suivi |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-PRF-1.1 | Les opérations les plus sensibles à la lenteur sont identifiées | Liste de 5 à 10 opérations critiques |
| DL-PRF-1.2 | Les durées de traitement sont journalisées | Historique consultable |
| DL-PRF-1.3 | Les ressources (CPU, mémoire, stockage, E/S) de production sont observables | Tableau de bord disponible |
| DL-PRF-2.1 | Une mesure de référence existe pour chaque opération critique (p50/p95) | Tableau daté |
| DL-PRF-2.2 | Les mesures sont faites sur un jeu de données de volume représentatif | Volume comparé à la production (≥ 50 %) |
| DL-PRF-2.3 | La méthode de mesure est écrite (répétitions, état du cache, conditions) | Protocole écrit |
| DL-PRF-2.4 | Les plans d'exécution des requêtes critiques sont conservés et compris | Plans archivés |
| DL-PRF-3.1 | Chaque opération critique a un budget de performance (temps, ressources) validé avec le métier | Document de budgets |
| DL-PRF-3.2 | Un test de performance automatisé détecte les régressions en CI ou en nuit | Une régression volontaire est détectée |
| DL-PRF-3.3 | Les optimisations sont décidées sur mesure (profil, plan), jamais sur intuition | Dossier avant/après pour 5 optimisations |
| DL-PRF-3.4 | Les accès aux données sont analysés (index, requêtes N+1, verrouillages) régulièrement | Revue trimestrielle |
| DL-PRF-3.5 | La fenêtre de traitement et sa marge sont connues | Durée / fenêtre disponible |
| DL-PRF-4.1 | Des tests de charge sont réalisés sur des volumes ≥ 3× le volume actuel | Rapports de test |
| DL-PRF-4.2 | La complexité algorithmique des traitements de masse est analysée (croissance du temps avec le volume) | Courbes durée = f(volume) |
| DL-PRF-4.3 | Un plan de capacité projette l'usage à 12 mois et son coût | Plan daté, révisé |
| DL-PRF-4.4 | Les traitements de masse sont incrémentaux ou partitionnables quand le volume l'exige | Traitement partiel prouvé |
| DL-PRF-4.5 | La marge de la fenêtre de traitement est ≥ 50 % | Mesure sur 3 mois |
| DL-PRF-5.1 | La mise à l'échelle est automatique ou déclenchée en < 1 h sur indicateur | Test de montée en charge |
| DL-PRF-5.2 | Le coût par unité de service (par utilisateur, par million de lignes) est suivi | Courbe de coût |
| DL-PRF-5.3 | Les régressions de performance en production sont détectées en < 1 jour par comparaison à la référence | Alerte sur dérive |
| DL-PRF-5.4 | Les choix de conception sont validés par prototypes de charge avant engagement | Dossier de prototype |
Lecture détaillée par niveau#
🟢 Niveau 1 — Subie#
- Signes : « c'est lent depuis lundi » ; correctifs d'urgence ; index ajoutés à l'aveugle.
- Gain : aucun investissement.
- Ne garantit pas : que la lenteur reste supportable quand le volume croît.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Mesurée#
- Signes : une table de durées de référence, un jeu de données représentatif, des plans d'exécution conservés. L'équipe parle en chiffres.
- Gain : une base de comparaison ; fin des débats d'opinion.
- Ne garantit pas : l'anticipation.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Budgétée#
- Signes : un budget (« la page se charge en moins de 2 s au p95 », « la consolidation termine en moins de 90 min ») et un test qui échoue s'il est dépassé. Les optimisations sont documentées avant/après.
- Gain : les régressions sont attrapées à la source.
- Ne garantit pas : la tenue à plus grand volume.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Prévue#
- Signes : on trace durée = f(volume) pour savoir si la croissance est linéaire ou quadratique ; on teste à ×3 ; on dispose d'un plan de capacité. Un traitement qui passe de 20 min à 80 min quand le volume double est un signal de complexité excessive.
- Gain : on investit avant la rupture, pas après.
- Ne garantit pas : l'élasticité automatique.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Élastique#
- Signes : mise à l'échelle sur indicateur ; coût rapporté à l'usage ; dérive détectée en production.
- Gain : performance et coût suivent la demande.
- Ne garantit pas : la maîtrise des coûts sans gouvernance — l'élasticité peut aussi faire dériver la facture.
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-PRF-3.2 : le test de performance existe, mais n'est exécuté qu'avant les versions majeures.
- 0,5 sur DL-PRF-4.1 : tests de charge à ×1,5 seulement.
- Un 5 partiel : coût par unité de service suivi, mise à l'échelle encore manuelle.
Optimiser sans mesurer. Symptôme : trois semaines pour gagner 2 % sur une étape qui pèse 3 % du total. Cause : intuition. Remède : profil d'abord ; viser la plus grande part du temps total.
Jeu de données trop propre. Symptôme : tout est rapide en recette, lent en production. Cause : volumes, distribution des valeurs et statistiques non représentatifs (biais de paramètres, asymétrie). Remède : jeu de volume réaliste et distribution réelle (anonymisée).
Mesurez sur plusieurs exécutions en alternance (A, B, A, B…) plutôt qu'en séquence ; sur plateforme partagée, comparez consommation CPU et lectures logiques, pas seulement la durée écoulée.
Une consolidation passe de 40 à 48 min avec +20 % de volume (croissance linéaire, marge confortable). Après ajout d'une jointure sur une colonne non indexée, elle passe de 48 min à 3 h : le test de non-régression nocturne (jalon 3.2) l'aurait signalée le lendemain, et le plan d'exécution conservé (2.4) montre un balayage complet.
Un budget fixé sur la moyenne est respecté en sacrifiant les cas extrêmes. Fixez-le sur un percentile élevé et surveillez la queue.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : table de références, jeu de données de volume réel, archivage des plans.
- 2 → 3 : budgets partagés avec le métier, test nocturne de non-régression.
- 3 → 4 : tests à ×3, courbes durée-volume, traitements incrémentaux ou partitionnés, plan de capacité.
- 4 → 5 : mise à l'échelle automatique, suivi du coût unitaire, détection de dérive en production.
Voir aussi#
- Voisins : 01 Architecture · 03 Tests · 08 Observabilité · 09 Dette technique.
- Autres matrices : BI — performance et volumétrie · BI — coût, licences et capacité · Data — pilotage coût et valeur.
- Pratique : CI/CD pour la data · pièges et bonnes pratiques · GDS et données SQL/BI.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
