Behebung allgemeiner Leistungsprobleme
Individuelle Optimierungstechniken sind wertvoll, aber echte Leistungsprobleme passen selten in eine einzelne Kategorie. Ein langsamer Bericht kann ein DAX-Problem, ein Kardinalitätsproblem und ein visuelles Designproblem auf einmal haben. Ein systematischer Problembehandlungsansatz hilft Ihnen dabei, Probleme effizient zu finden und zu beheben.
Befolgen Sie einen systematischen Diagnoseworkflow
Wenn ein Bericht langsam ist, verwenden Sie diesen dreistufigen Ansatz:
- Handelt es sich um das visuelle Element, den DAX oder die Daten? Öffnen Sie die Leistungsanalyse, löschen Sie den Cache, und aktualisieren Sie alle visuellen Elemente. Vergleichen Sie die DAX-Abfrage, die visuelle Darstellung und andere Zeitmessmetriken, um zu bestimmen, wo die Zeit genutzt wird.
- Isolieren Sie die Ursache. Kopieren Sie die langsame DAX-Abfrage, und führen Sie sie in der DAX-Abfrageansicht aus. Wenn die Abfrage dort schnell, im Visualisierer aber langsam ist, liegt das Problem im Rendering. Wenn die Abfrage überall langsam ist, liegt das Problem am Maßnahmen- oder Datenmodell.
- Korrigieren und Überprüfen. Wenden Sie den entsprechenden Fix an, und führen Sie dann die Leistungsanalyse erneut aus, um zu bestätigen, dass die Leistung verbessert wurde. Gehen Sie nicht davon aus, dass der Fix funktioniert hat: Messen Sie ihn.
Dieser Workflow (Symptom → Diagnose → Beheben → Überprüfen) verhindert, dass Sie Zeit mit dem falschen Problem verbringen und bestätigen, dass Ihre Änderungen tatsächlich helfen.
Führen Sie Best Practice Analyzer aus, um häufige Probleme zu erfassen.
Best Practice Analyzer (BPA) überprüft Ihr Semantikmodell anhand einer Reihe von mehr als 60 Regeln, die leistung, DAX-Ausdrücke, Fehlerprävention und Wartung abdecken. Anstatt jede Spalte und jedes Maß manuell zu überprüfen, überprüft BPA das gesamte Modell und kennzeichnet Probleme wie nicht verwendete Spalten, Schlüssel mit hoher Kardinalität, fehlende Beschreibungen und ineffiziente DAX-Muster.
In Microsoft Fabric ist BPA über Beispielnotizbücher verfügbar, die Sie direkt aus Ihrem semantischen Modell im Power BI-Dienst öffnen können. Wählen Sie das semantische Modell und dann das BPA-Notebook aus dem Menüband Start oder dem Dropdown-Menü Modellzustand aus. Das Notebook führt Ihr Modell mit Hilfe des semantischen Links aus und gibt kategorisierte Empfehlungen zurück. Ein Begleitnotizbuch zur Speicheranalyse zeigt Speicherstatistiken für Tabellen, Spalten und Beziehungen an.
BPA ist am nützlichsten als proaktive Überprüfung, bevor Leistungsprobleme auftreten. Führen Sie es nach dem Erstellen oder erheblichen Ändern eines Modells aus, und verwenden Sie die Ergebnisse, um die zuvor in diesem Modul behandelten Optimierungstechniken anzuwenden.
Hinweis
Wenn Sie keinen Zugriff auf Fabric haben, enthält Tabular Editor (ein externes Drittanbietertool) ein BPA-Feature, das denselben Regelsatz lokal für ein Power BI Desktopmodell oder ein veröffentlichtes Modell über den XMLA-Endpunkt ausführt.
Komplexe visuelle Inhalte ansprechen
Visuelle Elemente, die zu viele Daten anfordern, sind ein häufiges Leistungsproblem. Jedes visuelle Element auf einer Berichtsseite sendet separate DAX-Abfragen an das semantische Modell, und visuelle Elemente mit vielen Messwerten, Datenpunkten oder Cross-Filtering-Abhängigkeiten generieren komplexe Abfragen.
Häufige Probleme bei der visuellen Leistung:
- Zu viele Messungen auf einem Visualisierer. Ein Tabellenvisualisierung mit 20 Kennzahlen generiert eine große, komplexe Abfrage. Verringern Sie die Anzahl der Maßnahmen oder verteilen Sie die Informationen auf mehrere Grafiken.
- Zu viele Datenpunkte. Ein Punktediagramm mit 100.000 einzelnen Punkten oder eine Tabelle mit 50.000 Zeilen braucht viel Zeit zum Rendern. Wenden Sie top N-Filter an, um die zurückgegebenen Zeilen einzuschränken.
- Zu viele visuelle Elemente auf einer Seite. Jedes visuelle Element sendet Abfragen unabhängig voneinander. Eine Seite mit 30 visuellen Elementen fragt das Modell 30 mal beim Laden ab. Verwenden Sie Drillthrough-Seiten und Tooltips, um Informationen über Seiten hinweg zu verteilen, anstatt alles auf eine einzelne Seite zu komprimieren.
Tipp
Als allgemeine Richtlinie sollen nicht mehr als acht visuelle Elemente pro Berichtsseite verwendet werden. Mehr als das erhöht die Ladezeiten und macht den Bericht schwieriger zu verwenden.
Behebung schlecht konzipierter Beziehungen
Die Beziehungsgestaltung beeinflusst, wie der Motor die Filterausbreitung über Tabellen löst. Probleme, die man beachten sollte:
- Mehrdeutige Beziehungspfade. Mehrere aktive Pfade zwischen zwei Tabellen zwingen das Modul, zu bestimmen, welcher Pfad verwendet werden soll, was zu unerwarteten Ergebnissen und Leistungsaufwand führen kann. Verwenden Sie einzelne aktive Beziehungen und
USERELATIONSHIPin Maßnahmen, wenn Sie einen alternativen Pfad benötigen. - Bidirektionale Kreuzfilterung. Bidirektionale Beziehungen verteilen Filter in beide Richtungen, wodurch die Komplexität der Abfrageauswertung erhöht wird. Verwenden Sie bidirektionale Filter nur bei Bedarf, z. B. für Viele-zu-Viele-Beziehungen.
- Spalten für Beziehungen mit hoher Kardinalität. Beziehungen zu Spalten mit Millionen eindeutiger Werte (z. B. GUIDs) sind langsamer zu durchlaufen als Beziehungen zu Spalten mit niedrigerer Kardinalität. Verwenden Sie nach Möglichkeit stattdessen ganzzahlige Ersatztasten.
Beheben von Problemen mit dem Filterkontext
Teure Filterverteilung kann Abfragen auch dann verlangsamen, wenn die Measurelogik selbst einfach ist. Achten Sie auf diese Muster:
- REMOVEFILTERS oder ALL bei großen Tabellen. Diese Funktionen entfernen den Filterkontext, was bedeutet, dass das Modul die gesamte Tabelle ohne Einschränkungen auswerten muss. Verwenden Sie sie bewusst und nur im erforderlichen Umfang.
- M:n-Beziehungen mit großen Brückentabellen. Jede Abfrage löst die Zuordnung über die Brückentabelle auf. Bei großen Daten ist dieser Prozess teuer. Überlegen Sie, ob ein anderer Modellierungsansatz (z. B. Rollenspieldimensionen oder konsolidierte Tabellen) eine bessere Leistung erzielt.
Problembehandlung bei der DirectQuery-Performance
Wenn das Semantikmodell den DirectQuery-Speichermodus verwendet, kann die langsame Leistung von der externen Datenquelle und nicht vom DAX-Engine stammen. Zu den directQuery-spezifischen Problemen gehören:
- Fehler bei Query-Folding. Power Query versucht, Transformationen zurück an die Datenquelle zu verschieben (Abfragefaltung). Wenn eine Transformation nicht gefaltet werden kann, lädt Power BI die Rohdaten herunter und verarbeitet sie lokal. Dieser Ansatz ist viel langsamer. Überprüfen Sie die systemeigene Abfrage in Power Query, um die Faltung zu überprüfen.
- Langsame Quellabfragen. Selbst wenn die Abfragefaltung funktioniert, kann die Quelldatenbank die Abfrage aufgrund fehlender Indizes, großer Tabellenüberprüfungen oder Ressourcenkonflikten langsam ausführen. Arbeiten Sie mit Datenbankadministratoren zusammen, um die Quellleistung zu optimieren.
- Umlaufzeitlatenz. Jede visuelle Interaktion sendet eine Abfrage an die Datenquelle und wartet auf eine Antwort. Netzwerklatenz und Quellantwortzeit addieren sich, insbesondere auf Seiten mit vielen visuellen Elementen. Erwägen Sie gemischte Speichermodi mit "Importieren" für Zusammenfassungsdaten und DirectQuery für Detaildaten.
Verwenden von DAX Studio für eine tiefere Diagnose
Leistungsanalyse und DAX-Abfrageansicht behandeln die meisten Problembehandlungsszenarien. Wenn Sie Details auf Modulebene benötigen (z. B. ob eine Abfrage im Formelmodul oder Speichermodul eng ist), füllt DAX Studio die Lücke. Kopieren Sie eine langsame DAX-Abfrage aus der Leistungsanalyse, fügen Sie sie in DAX Studio ein, und aktivieren Sie Serveranzeigedauern , um genau zu sehen, wo Zeit aufgewendet wird. In der Abfrageplanansicht können auch ineffiziente Vorgänge angezeigt werden, die nicht allein aus Anzeigedauerdaten sichtbar sind.
Hinweis
SQL Server Profiler ist eine weitere Option zur vollständigen Überwachung aller DAX- und DirectQuery-SQL-Abfragen während einer Sitzung. Sie stellt eine Verbindung mit der lokalen Analysis Services-Instanz her, die von Power BI Desktop ausgeführt wird. Profiler ist nützlich für die sitzungsweite Analyse, aber für die meiste Fehlersuche auf visueller Ebene sind der Leistungsanalysator und DAX Studio praktischer.
Erstellen einer Prüfliste zur Problembehandlung
Wenn Sie einen langsamen Bericht untersuchen, gehen Sie diese Überprüfungen der Reihe nach durch:
- Löschen Sie den Cache, und führen Sie die Leistungsanalyse aus. Identifizieren Sie das langsamste visuelle Element und dessen Engpasskategorie.
- Wenn die DAX-Abfragezeit hoch ist, kopieren Und analysieren Sie die Abfrage in der DAX-Abfrageansicht oder DAX Studio. Suchen Sie nach teuren Mustern wie FILTER in großen Tabellen, Iteratoren oder wiederholten Unterausdrücken.
- Wenn die visuelle Anzeigezeit hoch ist, vereinfachen Sie das Visuelle, indem Sie die Anzahl der Measures, Datenpunkte oder das Anwenden von Filtern verringern.
- Überprüfen Sie die Kardinalität von Schlüsselspalten. Entfernen oder Reduzieren von Spalten mit hoher Kardinalität, die nicht benötigt werden.
- Überprüfen Sie bei DirectQuery-Modellen die Abfragefaltung und Quellleistung.
- Messen Sie nach jeder Änderung erneut, um die Verbesserung zu bestätigen.
Dieser strukturierte Ansatz stellt sicher, dass Sie zuerst die wirkungsvollsten Probleme behandeln und keine Zeit mit Änderungen verbringen, die die Nadel nicht verschieben.