Présentation de l’analyseur de performances Power BI

Ce blog décrit comment utiliser et interpréter les informations fournies par l’analyseur de performances Power BI, en recherchant les goulots d’étranglement dans les rapports lents.

Qu’est-ce que l’analyseur de performances Power BI ?

L’analyseur de performances Power BI est une fonctionnalité incluse dans la version de mai 2019 de Power BI Desktop qui simplifie la façon dont vous pouvez collecter les requêtes DAX générées par Power BI. Vous pouvez utiliser DAX Studio pour les capturer, mais l’analyseur de performances intégré à Power BI est plus simple et fournit quelques informations sur le temps consommé dans d’autres activités, telles que le temps de rendu de tous les visuels.

Vous pouvez activer l’Analyseur de performances Power BI en cochant la case Analyseur de performances dans le ruban Affichage Power BI Desktop.

Vous pouvez trouver plus de détails sur l’interface utilisateur dans le Documentation de l’analyseur de performances par Microsoft. Ce blog vise à se concentrer sur les mesures fournies par cette fonctionnalité et à vous aider à interpréter correctement les données.

Par exemple, commençons par capturer le timing des visuels.

1. Ouvrez le fichier PBIX
2. Activez le volet Analyseur de performances,
3. Cliquez sur Démarrer l’enregistrement dans le volet Analyseur de performances

Passer à une autre page du rapport,

Le volet Analyseur de performances capture la durée en millisecondes pour chaque visuel de la page. Le visuel Matrix est le plus lent – bien que le timing puisse varier selon le matériel – mais chaque visuel peut afficher environ 2 secondes de durée.

Cliquez sur le bouton Actualiser les visuels dans le volet Analyseur de performances et faites défiler vers le bas pour voir la durée des visuels pour la deuxième exécution. La matrice est toujours le visuel le plus lent, mais le temps d’exécution de chaque visuel a été réduit depuis la première exécution.

À ce stade, vous avez deux exécutions des mêmes visuels dans le volet Analyseur de performances. Le premier groupe est lié à un Page modifiée événement, et la durée est d’au moins deux secondes pour presque tous les visuels. En sélectionnant l’un de ces visuels, vous voyez que la plupart du temps est passé dans la section « Autre ».

La Durée de chaque visuel est le temps passé dans trois catégories :

• Requête DAX: chaque visuel génère une ou plusieurs instructions EVALUATE dans une seule requête envoyée au moteur tabulaire. Il s’agit du temps écoulé entre la requête envoyée au moteur et la première ligne du résultat reçue par Power BI. Certains visuels ne génèrent aucune requête DAX. Cette durée peut être exécutée en parallèle des actions requises par d’autres visuels.
• Affichage visuel: c’est le temps nécessaire pour rendre le visuel. Il s’agit du temps passé côté client uniquement et dans le thread unique de l’interface utilisateur.
• Autre: c’est le temps passé à attendre que d’autres opérations se terminent. Il s’agit généralement du temps de synchronisation entre différents visuels d’une même page et ne doit pas être considéré comme un goulot d’étranglement du visuel en cours d’analyse. Il s’agit généralement d’un temps d’attente causé par d’autres opérations en attente effectuées par d’autres visuels.

Supposons que vous compariez la durée de la première exécution de la page Sales avec la seconde exécution. Dans ce cas, vous pouvez voir que ce dernier a une durée plus courte car il réduit la Autre durée de chaque visuel. La raison en est que la première exécution de visuels et de requêtes sur le modèle de données nécessite une allocation de nouvelles structures en mémoire ; il ne peut être réduit que si vous réduisez le nombre de visuels et la taille des tables du modèle de données. Pour cette raison, vous devez vous concentrer principalement sur la durée générée lorsque vous cliquez sur Actualiser les visuels. De cette façon, vous ignorez le temps de chargement initial du rapport et du modèle de données.

Supposons que la durée de l’affichage visuel est longue. Dans ce cas, vous devez déterminer si vous pouvez l’améliorer en réduisant la quantité de données incluses dans le visuel (par exemple, en réduisant le nombre de points de données dans une carte ou un graphique) ou en remplaçant le visuel par un autre. Il est normal de voir une durée plus longue pour les visuels personnalisés par rapport aux visuels natifs dans Power BI. Cependant, chaque visuel a un coût en mémoire et en CPU. La présence de nombreux visuels dans une seule page Power BI peut affecter les performances car le rendu de chaque visuel est une opération séquentielle exécutée dans un seul thread. Comme vous le voyez dans la capture d’écran suivante, même une simple zone de texte nécessite près de 100 millisecondes, il n’est donc pas rare d’attendre plusieurs secondes simplement parce qu’une seule page contient des dizaines de visuels.

Un lent Requête DAX a une longue durée et mérite une enquête plus approfondie. La raison peut être une mesure lente, un modèle de données lent ou une source de données lente, en particulier lors de l’utilisation de DirectQuery. Par exemple, la capture d’écran suivante montre que le visuel le plus lent de l’exemple de rapport (matrice) a une requête DAX très lente.

Vous pouvez copier la requête dans le presse-papiers en appuyant sur Copier la requête. Collez la requête dans DAX Studio pour répéter l’exécution de la requête, cette fois en activant davantage d’outils de diagnostic à l’aide des options de traçage du plan de requête et des minutages du serveur. Éventuellement, exécutez la requête DAX dans DAX Studio en vidant d’abord le cache – Performance Analyzer ne vide pas le cache du moteur tabulaire avant chaque exécution.

Voici le code généré pour remplir le visuel Matrix :

La requête appelle la mesure Customers, qui est définie comme suit :

Le but de ce blog n’est pas d’expliquer en détail pourquoi cette mesure client spécifique est lente. Nous pouvons simplement mentionner que l’utilisation d’un filtre de table combiné à une agrégation DISTINCTCOUNT crée un plan de requête inefficace. La modification du code à l’aide d’un filtre de colonne sémantiquement équivalent produit un plan de requête optimal :

En actualisant le visuel, il est possible de voir l’amélioration significative apportée à la requête DAX, qui s’exécute désormais en moins de 10 millisecondes

Cependant, la durée de Autre a maintenant augmenté en raison de la présence de plusieurs visuels, et Matrix n’est plus la requête la plus lente sur la page de rapport.

En raison de sa nature, la Durée indiquée dans Autre doit être ignorée. La plupart du temps Autre n’est pas ajouté entre les visuels. Étant donné que la durée totale du visuel indique la somme des trois catégories, il est plus difficile d’isoler la requête en cours d’exécution la plus lente. Ce serait une bonne idée de pouvoir isoler la durée Autre, en additionnant uniquement les durées d’affichage de la requête DAX et du visuel pour chaque visuel, ce qui accélérerait l’identification du principal goulot d’étranglement dans un rapport.

Bonne lecture. Merci à tous pour vos commentaires. Ceci est mon 11ème Blog en 3 mois. Lors de la rédaction de mon premier blog, je n’aurais jamais pensé que j’écrirais plus de 10 blogs en un trimestre. J’espère que cela motivera les gens à créer plus de blogs à l’avenir. Merci!