Résoudre les problèmes de performance courants

Les techniques d’optimisation individuelles sont précieuses, mais les problèmes de performances réels s’intègrent rarement dans une catégorie unique. Un rapport lent peut avoir un problème DAX, un problème de cardinalité et un problème de conception visuelle en même temps. Une approche de dépannage systématique vous permet de trouver et de résoudre efficacement les problèmes.

Suivre un flux de travail de diagnostic systématique

Lorsqu’un rapport est lent, utilisez cette approche en trois étapes :

1. Est-ce le visuel, le DAX ou les données ? Ouvrez l’analyseur de performances, effacez le cache et actualisez tous les visuels. Comparez la requête DAX, l’affichage visuel et d’autres mesures de temps pour déterminer où le temps est utilisé.
2. Isolez la cause racine. Copiez la requête DAX lente et exécutez-la dans la vue de requête DAX. Si la requête est rapide, mais lente dans la visualisation, le problème est le rendu. Si la requête est lente partout, le problème est la mesure ou le modèle de données.
3. Corrigez et vérifiez. Appliquez le correctif approprié, puis réexécutez l’analyseur de performances pour confirmer que les performances ont été améliorées. Ne supposez pas que le correctif a fonctionné : mesurez-le.

Ce flux de travail (symptôme → diagnostic → corriger → vérifier) vous empêche de passer du temps sur le problème incorrect et confirme que vos modifications aident réellement.

Exécuter Best Practice Analyzer pour détecter les problèmes courants

Best Practice Analyzer (BPA) vérifie votre modèle sémantique par rapport à un ensemble de plus de 60 règles qui couvrent les performances, les expressions DAX, la prévention des erreurs et la maintenance. Au lieu d’inspecter manuellement chaque colonne et mesure, BPA analyse l’ensemble du modèle et signale les problèmes tels que les colonnes inutilisées, les clés de cardinalité élevée, les descriptions manquantes et les modèles DAX inefficaces.

Dans Microsoft Fabric, le BPA est disponible via des carnets d’échantillons que vous pouvez ouvrir directement à partir de votre modèle sémantique dans le service Power BI. Sélectionnez le modèle sémantique, puis choisissez le bloc-notes BPA dans le ruban Accueil ou la liste déroulante État du modèle. Le notebook s’exécute sur votre modèle à l’aide d’un lien sémantique et retourne des recommandations classées. Un cahier complémentaire Memory Analyzer affiche des statistiques de stockage pour les tables, les colonnes et les relations.

Le BPA est particulièrement utile en tant que vérification proactive avant que des problèmes de performances n’apparaissent. Exécutez-le après avoir généré ou modifié considérablement un modèle et utilisez les résultats pour guider les techniques d’optimisation décrites précédemment dans ce module.

Traiter des visuels complexes

Les visuels qui demandent trop de données sont un problème de performances courant. Chaque visuel d’une page de rapport envoie des requêtes DAX distinctes au modèle sémantique et des visuels avec de nombreuses mesures, points de données ou dépendances de filtrage croisé génèrent des requêtes complexes.

Problèmes courants de performances visuelles :

• Trop de mesures sur un seul visuel. Un visuel de table avec 20 mesures génère une requête volumineuse et complexe. Réduisez le nombre de mesures ou fractionnez les informations sur plusieurs visuels.
• Points de données trop nombreux. Un nuage de points avec 100 000 points individuels ou une table avec 50 000 lignes prend beaucoup de temps à afficher. Appliquez les filtres N principaux pour limiter les lignes retournées.
• Trop de visuels sur une page. Chaque visuel envoie des requêtes indépendamment. Une page avec 30 visuels interroge le modèle 30 fois au chargement. Utilisez des pages de drill-through et des info-bulles pour répartir les informations sur plusieurs pages plutôt que de tout entasser sur une seule page.

Corriger les relations mal conçues

La conception des relations affecte la façon dont le moteur résout la propagation du filtre à travers les tables. Problèmes à rechercher :

• Chemins de relation ambigus. Plusieurs chemins actifs entre deux tables forcent le moteur à déterminer le chemin d’accès à utiliser, ce qui peut entraîner des résultats inattendus et une surcharge de performances. Utilisez des relations actives uniques et USERELATIONSHIP dans les mesures lorsque vous avez besoin d’un chemin alternatif.
• Filtrage croisé bidirectionnel. Les relations bidirectionnelles propagent des filtres dans les deux sens, ce qui augmente la complexité de l’évaluation des requêtes. Utilisez le filtrage bidirectionnel uniquement si nécessaire, par exemple pour les relations plusieurs-à-plusieurs.
• Colonnes de relation de cardinalité élevée. Les relations sur les colonnes avec des millions de valeurs uniques (comme les GUID) sont plus lentes à parcourir que les relations sur les colonnes avec une cardinalité inférieure. Si possible, utilisez plutôt des clés de substitution entières.

Résoudre les problèmes de contexte de filtre

La propagation de filtre coûteuse peut ralentir les requêtes même lorsque la logique de mesure elle-même est simple. Surveillez ces modèles :

• REMOVEFILTERS ou ALL sur des tables volumineuses. Ces fonctions suppriment le contexte de filtre, ce qui signifie que le moteur doit évaluer la table entière sans aucune restriction. Utilisez-les intentionnellement et uniquement à l’étendue nécessaire.
• Relations plusieurs-à-plusieurs avec de grandes tables de pont. Chaque requête résout le mappage via la table de pont. Avec les données volumineuses, ce processus est coûteux. Déterminez si une approche de modélisation différente (comme les dimensions de rôle ou les tables consolidées) s’améliore.

Résoudre les problèmes de performances de DirectQuery

Lorsque le modèle sémantique utilise le mode de stockage DirectQuery, les performances lentes peuvent provenir de la source de données externe plutôt que du moteur DAX. Les problèmes spécifiques à DirectQuery sont les suivants :

• Échecs de repliement de requêtes. Power Query tente de renvoyer des transformations vers la source de données (pliage des requêtes). Lorsqu'une transformation ne peut pas se plier, Power BI télécharge les données brutes et les traite localement. Cette approche est beaucoup plus lente. Passez en revue la requête native dans Power Query pour vérifier le pliage.
• Requêtes de source lentes. Même lorsque le pliage des requêtes fonctionne, la base de données source peut exécuter la requête lentement en raison d’index manquants, d’analyses de tables volumineuses ou de contention de ressources. Collaborez avec les administrateurs de base de données pour optimiser les performances de la source.
• Latence aller-retour. Chaque interaction visuelle envoie une requête à la source de données et attend une réponse. La latence réseau et le temps de réponse source s’ajoutent, en particulier sur les pages avec de nombreux visuels. Envisagez les modes de stockage mixtes avec Import pour les données récapitulatives et DirectQuery pour les données détaillées.

Utiliser DAX Studio pour des diagnostics plus approfondis

L’analyseur de performances et la vue de requête DAX gèrent la plupart des scénarios de résolution des problèmes. Lorsque vous avez besoin de détails au niveau du moteur (par exemple, pour savoir si une requête est bloquée dans le moteur de formule ou le moteur de stockage), DAX Studio comble cette lacune. Copiez une requête DAX lente à partir de l’analyseur de performances, collez-la dans DAX Studio et activez les minutages du serveur pour voir exactement où le temps est passé. La vue Plan de requête peut également révéler des opérations inefficaces qui ne sont pas visibles uniquement à partir des données de minutage.

Créer une liste de contrôle de résolution des problèmes

Lors de l’examen d’un rapport lent, effectuez ces vérifications dans l’ordre :

1. Effacez le cache et exécutez l’analyseur de performances. Identifiez le visuel le plus lent et sa catégorie de goulot d’étranglement.
2. Si le temps de requête DAX est élevé, copiez et analysez la requête en mode requête DAX ou DAX Studio. Recherchez des modèles coûteux comme FILTER sur des tables volumineuses, des itérateurs ou des sous-expressions répétées.
3. Si le temps d’affichage visuel est élevé, simplifiez le visuel en réduisant le nombre de mesures, de points de données ou d’application de filtres.
4. Vérifiez la cardinalité des colonnes clés. Supprimez ou réduisez les colonnes à cardinalité élevée qui ne sont pas nécessaires.
5. Pour les modèles DirectQuery, vérifiez le pliage des requêtes et les performances de la source.
6. Après chaque modification, mesurez à nouveau pour confirmer l’amélioration.

Cette approche structurée garantit que vous résolvez d’abord les problèmes les plus impactants et ne passez pas de temps sur les modifications qui ne déplacent pas l’aiguille.