i

Description

Sablier de bureau : le temps que l'on attend s'écoule grain par grain.

Source

Suohros · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Performance et volumétrie

Ce thème mesure le temps que l'utilisateur attend (ouverture, clic sur un filtre, export) et la capacité du produit à tenir sa promesse quand les données grossissent. Il traite la…

En bref

Ce thème mesure le temps que l'utilisateur attend (ouverture, clic sur un filtre, export) et la capacité du produit à tenir sa promesse quand les données grossissent. Il traite la cardinalité des colonnes, la taille du modèle, les modes de stockage (Import, DirectQuery, Dual, Direct Lake), les agrégations, le nombre de visuels, et l'analyse des requêtes (Performance Analyzer, DAX Studio, plans de requête).

Sur cette page

1. 1. Pourquoi ce thème
2. 2. Ce que mesure le thème
3. 3. Les 5 niveaux
4. 4. Jalons par niveau
5. 5. Lecture détaillée par niveau
   1. 🟢 Niveau 1 — Subi
   2. 🟢 Niveau 2 — Mesuré
   3. 🟡 Niveau 3 — Piloté
   4. 🟡 Niveau 4 — Budgété
   5. 🔴 Niveau 5 — Garanti
6. 6. Atteinte partielle et notation
7. 7. Passer au niveau suivant
8. 8. Voir aussi

Niveau : 🟢→🔴 · Code thème : PRF

1. Pourquoi ce thème#

Un rapport lent n'est pas « utilisé moins » : il est contourné (export Excel, requête SQL directe, copie locale), ce qui détruit la gouvernance. Les repères d'usage couramment admis : en dessous d'environ 1 s, l'utilisateur ne perçoit pas d'attente ; autour de 10 s, il décroche (ordres de grandeur, issus de la recherche en ergonomie ; à adapter). La performance d'un modèle Import se joue d'abord sur la cardinalité et la taille (moteur colonnaire VertiPaq), puis sur la qualité du DAX (DAX), puis sur la page (nombre de visuels).

2. Ce que mesure le thème#

• Axe : du « ça rame, on ne sait pas pourquoi » au temps de réponse garanti par un budget mesuré en pipeline.
• Indicateurs clés : durée d'affichage de page (P50/P95), durée de requête DAX par visuel, taille du modèle (Mo/Go), durée du rafraîchissement, part de requêtes DirectQuery > 3 s.
• Unités : secondes, Mo, nombre de visuels par page.

3. Les 5 niveaux#

4. Jalons par niveau#

5. Lecture détaillée par niveau#

🟢 Niveau 1 — Subi#

• Signes : « c'est lent depuis lundi », aucun chiffre. Ou, pire : personne ne se plaint parce que personne n'utilise.
• Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Mesuré#

• Signes : Performance Analyzer exploité, taille de modèle connue, colonnes inutiles supprimées (gain de taille souvent de 20 à 50 % dans un modèle jamais nettoyé — ordre de grandeur).
• Gain : on cesse de deviner. Limite : chaque mesure est ponctuelle.
• Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Piloté#

• Signes : on sait lire la différence entre le temps moteur de formule (Formula Engine) et moteur de stockage (Storage Engine) ; on traite d'abord la cardinalité (un horodatage à la seconde sur 100 M de lignes ruine la compression), puis le DAX, puis la page. Les agrégations couvrent les requêtes fréquentes.

-- Dans DAX Studio : lire les timings serveur
EVALUATE
SUMMARIZECOLUMNS (
    'DIM_DATE'[Mois],
    'DIM_COMMERCIAL'[Region],
    "Visites", [Nb Visites]
)

• Gain : l'optimisation est ciblée. Limite : sans budget, la performance se dégrade version après version.
• Difficulté : 3/5 · Effort : 3/5.

🟡 Niveau 4 — Budgété#

• Signes : chaque livraison passe un jeu de requêtes de référence (ex. 20 requêtes DAX extraites de Performance Analyzer, rejouées par script) et compare les durées à la version précédente. Un dépassement de seuil bloque ou alerte.
• Gain : la régression se voit avant l'utilisateur.
• Limite : le budget se périme si les usages changent.
• Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Garanti#

• Signes : test de charge concurrente, projection de croissance, cible P95 tenue. Choix d'architecture assumés : Import pour le chaud, DirectQuery/Direct Lake pour le très volumineux, agrégations automatiques ou manuelles, partitions.
• Gain : la performance cesse d'être une surprise.
• Limite : coût (capacité, CST) ; arbitrage fraîcheur/vitesse.
• Difficulté : 5/5 · Effort : 5/5.

6. Atteinte partielle et notation#

Règle commune. « Un 5 partiel » : le P95 est tenu en conditions nominales mais aucun test de charge n'a été mené (BI-PRF-5.1 = 0), la projection de croissance existe (5.2 = 1), la cible P95 est atteinte sur 3 pages sur 5 (5.3 = 0,5) ; le niveau 5 n'est pas acquis tant qu'un jalon est à 0.

7. Passer au niveau suivant#

Moyens possibles (facultatifs) :

Pièges :

• Optimiser la mesure qui coûte 40 ms alors que la page lance 25 visuels : toujours chercher d'abord le plus gros contributeur.
• Goodhart : un budget « < 3 s » atteint en masquant les visuels lents derrière des signets : la lenteur est cachée, pas résolue.
• Les mesures sur capacité partagée varient selon la charge environnante : mesurer en alternance, plusieurs fois, jamais une seule exécution.

8. Voir aussi#

• Thèmes voisins : MOD · DAX · ETL · OPS · CST
• Autres matrices : DL — performance et scalabilité
• Contenus : OneLake — architecture · SQL Server SaaS — difficultés et pièges · Comparatif OneLake vs SQL Server · Bonnes pratiques Power BI

✻ Rédigé par Claude Sonnet 5.5