Comment troubleshoot les problèmes de performances sur Power BI

Introduction

Le système d’alerting par défaut dans Power BI se limite majoritairement à prévenir lors de l’échec du rafraichissement programmé des jeux de données. Il est donc courant que ce soit les utilisateurs des rapports qui fasse directement remonter les problèmes de latence, voir d’indisponibilités.

Dans ce genre de cas, il est indispensable de pouvoir répondre rapidement aux utilisateurs. Pour identifier les causes précises de ces problèmes il existe plusieurs outils, natifs à Power Bi comme externes, qu’on présentera dans cet article.

Monitoring dans PBI Service

Les ressources de calcul peuvent être consommées soit lors du rafraichissement des données, soit par les requêtes interactives lors de la consultation des rapports. Suivant l’origine des pics de demandes de ressources, les outils de monitoring ne seront pas les mêmes.

Monitoring des activités

Sur Power Bi Service et donc sur Microsoft Fabric, il existe un monitoring intégré des dernières activités, tout workspace confondu.

Ce monitoring regroupe tous les types d’activités de Microsoft Fabric et pas uniquement les rafraichissements de données. Il peut donc être nécessaire de filtrer sur le type d’activité qui nous intéresse, à savoir Item Type = Semantic model

Ici on peut voir le statut et le temps de traitement des rafraichissements des jeux de données. On se faire une première idée de la généralisation du problème :

• Est-ce que des rafraichissements de données sont en échec ?
• Est-ce que les temps de rafraîchissement de données sont plus long que d’habitude ? Y a-t-il eu un pic ou l’augmentation a été progressive ?
• Est-ce que cela concerne la totalité des rapports ? la totalité des workspaces ?

Création d’un dashboard de monitoring custom

Cette visualisation des rafraîchissements est loin d’être optimale pour notre besoin de vue d’ensemble. Si on souhaite avoir une visualisation plus spécifique, Power BI propose le jeu de données (via l’API Power BI) des informations des workspaces, rapports, datasets, etc. sur lesquels on peut construire un rapport plus adapté que la visualisation native vue précédemment.

Pour accéder à ces données, il faut télécharger le connecteur Power BI API et le déposer dans le dossier des connecteurs externes (ce n’est pas un connecteur official : https://github.com/migueesc123/PowerBIRESTAPI) .

Il peut ensuite être nécessaire de désactiver une sécurité pour que notre rapport soit en mesure d’utiliser ce connecteur non natif.

Une fois les données accessibles, on peut s’y connecter via ce menu : File > Get data > Get data to get started > Power Platform > Power BI API (Beta) (Custom)

On a alors un ensemble de tables (plus ou moins grand suivant les droits qu’on a sur les workspaces), dont on va sélectionner uniquement celles relatives au rafraichissement des données. Les relations entre les tables sont automatiquement créées, consultables dans l’onglet « view model »

Ici un exemple de quelques visuels simples qui peuvent aider à identifier la mesure du problème : évolution du temps de rafraîchissement de tous les jeux de données, date et statut des derniers rafraichissement de chacun des jeux de données et liste des dernières erreurs.

Monitoring de la Capacité Fabric

Une autre visualisation des rapports, dans le cas où une Capacité est utilisée (Capacité Premium ou Capacité Fabric) est le dashboard de monitoring des performances (et du stockage). Dans le cas où on n’utilise pas de Capacité (simple licence Power Bi ou compte d’essai Fabric par exemple), ce sont les serveurs de Microsoft qui se chargent des calculs, qu’on ne peut donc pas monitorer.

Pour accéder à la Capacity Metric App, il faut être Admin de la Capacité et l’installer à partir du panneau ‘Apps’, puis ‘Get App’. Si vous n’êtes pas Admin, vous devriez pouvoir trouvez l’application dans la liste proposée mais pas l’installer.

Une fois installée l’application est disponible dans notre liste d’application, et on retrouve 2 panneaux, celui de la partie Compute et celui de la partie Storage. Ici seule la partie Compute nous intéressera.

De façon non exhaustive on peut y consulter l’évolution de l’utilisation de la capacité et comment la capacité a été utilisée : traitements en arrière-plan comme les rafraichissements de données, ou des traitements en temps-réel comme l’exécution des requêtes d’un rapport par un utilisateur qui consulte une application. On a un détail des éléments responsables de ces traitements en dessous.

On peut explorer un moment précis de la journée (en sélectionnant une barre du graphe on active le bouton ‘Explore en dessous’), ce qui offre la possibilité de consulter chaque opération de chaque élément qui a consommé de la puissance de calcul sur la période de temps données.

Si le rapport est consulté, le grain de monitoring le plus fin reste la maille ‘jeu de données, et on ne pourra pas déterminer ici quels visuels ou mesure DAX pourraient être en cause.

Monitoring d’utilisation des rapports

Si on souhaite avoir une vision plus globale sur un seul rapport, on peut en obtenir ses metrics d’utilisation. En cliquant sur “View usage metrics report” d’un rapport, on obtient un rapport (qu’on peut enregistrer) pour avoir des informations sur la consultation de ce rapport.

Ce genre d’informations pour donner des insights sur la consommation du rapport peut donner des pistes d’amélioration du rapport pour augmenter ses performances.

Troubleshooting avec DAX Studio

Le monitoring à partir de Power Bi Service ne permet pas d’explorer le code derrière un rapport, et donc d’en monitorer finement chaque élément. Ainsi une fois un rapport identifié, il peut être nécessaire de faire un contrôle plus fin de ses performances via Power Bi Desktop. L’outil qu’on utilisera pour cela est DAX Studio.

Fonctionnement et installation de l’outil

DAX Studio est un outil externe à Power Bi mais qui s’y intègre facilement. On l’installe via un installer téléchargeable sur leur site (https://daxstudio.org/), puis on pourra le lancer à partir de n’importe quel rapport ouvert sur Power Bi Desktop dans l’onglet External Tools.

Si on exécute DAX Studio sans passer par Power Bi Desktop, DAX Studio propose soit de se connecter à un rapport déjà ouvert dans Power Bi Desktop, soit de se connecter directement à un serveur. Nous ne couvrirons que le premier choix dans cet article.

Une fois un rapport chargé, on a accès aux données de ce rapport, tables, colonnes et mesures par exemple (panneau de gauche). On peut jouer des requêtes DAX en les utilisant, de la même façon qu’on le ferait sur notre rapport (panneau central). À chaque requête exécutée, on peut consulter le résultat mais aussi les logs et donc les temps de traitement. Couplé à l’onglet ‘History’, on peut suivre l’évolution du temps de traitement d’une mesure au fil des modifications qu’on lui apporte, ce qui est indispensable pour valider une non-régression des performances.

Il est important de noter que pour éviter les biais, il faut rejouer plusieurs fois la même mesure car la puissance de calcul utilisée est celle de notre ordinateur (car on travaille en local, n’ayant pas choisi de se brancher sur un serveur), et cette puissance n’est pas constante. En effet si on joue une mesure au moment où notre processeur est déjà occupé, le temps de traitement sera plus long qu’au moment où on jouerait la même mesure mais au moment où le processeur ne l’est pas. La moyenne des temps de traitement est alors un bon compromis.

Il faut de plus penser à vider le cache entre chaque mesure (facilité par l’option Clear on Run). Si le cache n’est pas vidé alors seule la première requête serait fidèle à ce qu’aurait un nouvel utilisateur.

Import des performances, utilisation de l’outil

Dans le cas d’un troubleshooting de rapport, on ne veut pas créer de nouvelles mesures DAX mais analyser les requêtes déjà présentes dans un rapport. On peut recréer ou copier une à une les requêtes dans DAX Studio, mais on peut aussi exporter l’ensemble des requêtes en une fois.

Dans Power Bi Desktop, dans l’onglet “Optimize” on peut cliquer sur “Performance Analyzer”. Cela ouvre un panneau permettant d’enregistrer les requêtes et leurs performances résultant de nos actions sur le rapport, entre le début et la fin de l’enregistrement.

Le cas le plus classique est de débuter l’enregistrement, rafraichir les visuels, simulant un premier chargement de la page sur laquelle on se trouve, et de couper l’enregistrement. On obtient alors les performances du chargement de la page, ce qui la première étape d’optimisation du rapport. En effet il probable que les requêtes lors de la sélection de filtre sur la page profitent des mêmes optimisations.

L’export de ces résultats se fait sous la forme d’un fichier JSON, qui est chargeable dans DAX Studio avec le bouton “Load Perf Data”. On obtient les temps d’exécution des requêtes pour chaque visuel de la page. En consultant la requête, on peut identifier quelles mesures, tables et colonnes sont utilisées, et donc donner des pistes d’amélioration.

DAX Studio simplifie le travail de debug en permettant d’écrire du code au-dessus de la requête, par exemple pour écraser la définition d’une mesure, pour vérifier si en la modifiant l’exécution de la requête serait plus rapide.

Pour modifier la définition d’une mesure, il suffit de la trouver dans l’arborescence à gauche puis en faisant clique droit de sélectionner ‘Define measure’, ce qui ajoutera automatiquement la mesure en haut de notre panneau central.

Vertipaq Analyzer

DAX Studio intègre maintenant l’outil Vertipaq Analyzer. À la base cet outil est indépendant et on peut le télécharger sous la forme d’un fichier Excel sans DAX Studio (https://www.sqlbi.com/tools/vertipaq-analyzer/). Si on l’utilise de cette manière, il faut penser à débloquer la sécurité du fichier pour profiter des macros. En important le fichier de performances dans le fichier Excel (le même fichier qu’on a importé précédemment dans DAX Studio), on obtient de nouveaux indicateurs sur nos données.

En passant par DAX Studio, il suffit de choisir “View Metrics” dans l’onglet “Advanced”. Cela ouvrira un nouveau panneau “Vertipaq Analyzer” avec les mêmes données que celles de l’Excel.

Vertipaq Analyzer renvoie principalement des statistiques sur nos données : la cardinalité de chaque colonne, le poids de chaque tables, les relations les plus Lourdes etc. Ces nouveaux indicateurs offrent de nouvelles pistes d’amélioration, concernant cette fois principalement le modèle de données (gestion de la quantité de données, du choix des colonnes, du type des colonne, etc.).

Dans le cas où les compétences en interne ne sont pas suffisantes pour analyser le problème, on peut avoir besoin de transmettre le maximum d’information à quelqu’un d’autre, sans forcément lui envoyer les données qui peuvent être sensible. Vertipaq Analyzer permet d’exporter un rapport utiliser par une autre personne sur son propre Vertipaq Analyzer, via les boutons ”Export Metrics” (et “Import Metrics”). Ainsi seuls les statistiques seront envoyés et pas les données, permettant à un intervenant extérieurs d’analyser la situation sans compromettre les données.

Conclusion

Nous avons vu de multiples moyens d’identifier les causes d’un problème de performance sur Power Bi, du plus large au niveau de la Capacité et de l’ensemble des workspaces, au plus fin au niveau de chaque visuel, requête et mesures jouées.

Une fois les causes déterminées et les axes d’améliorations choisis, il est souvent nécessaire d’effectuer des actions correctives. Pour cela d’autres outils existent pour faciliter le travail, notamment Best Practice Analyzer, que nous couvrirons dans le prochain article.