Power BI Performance optimieren: Engpässe gezielt finden

Ein Power-BI-Bericht lädt langsam, Filter reagieren verzögert, und zum Monatsabschluss verschärft sich das Problem. Liegt es an DAX, zu vielen Visuals oder der Kapazität? Wer jetzt auf Verdacht Measures umschreibt oder zusätzliche Ressourcen kauft, behandelt möglicherweise die falsche Ursache.

Wenn Du die Power BI Performance optimieren möchtest, brauchst Du zuerst einen reproduzierbaren Diagnoseablauf. Dieser Artikel zeigt Dir, wie Du bestehende Berichte untersuchst, Engpässe voneinander trennst und Verbesserungen nach ihrer messbaren Wirkung priorisierst.

Kurz gesagt: Power BI Performance lässt sich gezielt verbessern, wenn Du zuerst die langsame Nutzeraktion misst und anschließend Datenmodell, DAX, Visuals, Datenquelle und Kapazität systematisch prüfst. Der Performance Analyzer liefert den Einstieg; vertiefende Messungen zeigen, welche Ursache tatsächlich dominiert. Priorität erhalten Änderungen, die häufig genutzte Abläufe nachweisbar beschleunigen, ohne fachliche Ergebnisse oder Berechtigungen zu verändern.

Wie kannst Du Power BI Performance optimieren, ohne auf Verdacht zu arbeiten?

Eine belastbare Performance-Optimierung beginnt mit einem reproduzierbaren Testszenario und einer Vergleichsmessung. Erst wenn derselbe Ablauf unter vergleichbaren Bedingungen wiederholt wird, lässt sich die Wirkung einer Änderung bewerten.

Definiere zunächst die langsame Aktion: das Öffnen einer Seite, eine Filterauswahl oder einen Drillthrough. Halte dabei fest:

• Bericht, Seite und Filterzustand
• Power BI Desktop oder Power BI Service
• Speichermodus: Import, DirectQuery, Direct Lake oder ein zusammengesetztes Modell
• verwendete Identität und gegebenenfalls Row-Level Security
• Zeitpunkt, Datenstand und parallele Nutzung
• Ladezeit der Aktion und Laufzeit auffälliger Visuals

Miss die Aktion mehrfach. Trenne den ersten Aufruf von Wiederholungen, weil Caches Ergebnisse beeinflussen. Vergleiche nicht einen kalten Erstaufruf mit einem bereits aufgewärmten Bericht.

Der Diagnoseablauf

1. Symptom abgrenzen: Ist eine Interaktion langsam, der gesamte Bericht oder nur die Datenaktualisierung?
2. Visuals messen: Zeichne den Ablauf mit dem Performance Analyzer auf.
3. Abfragen untersuchen: Prüfe auffällige DAX-Abfragen und das zugrunde liegende Modell.
4. Externe Wartezeiten prüfen: Untersuche bei Bedarf Datenquelle, Gateway und Netzwerk.
5. Betrieb vergleichen: Tritt das Problem vor allem im Service oder unter gleichzeitiger Nutzung auf, prüfe die Kapazität.

Dieser Ablauf ist eine Untersuchungsreihenfolge, keine starre Ursachenkette. Eine langsame DAX-Abfrage kann beispielsweise durch ein ungünstiges Modell oder bei DirectQuery durch die Quelle verursacht werden.

Wie erkennst Du, ob Datenmodell oder DAX der Engpass ist?

Datenmodell und DAX müssen gemeinsam untersucht werden, weil dieselbe Berechnung je nach Modellstruktur unterschiedlich viel Arbeit verursacht. Die Laufzeit einer DAX-Abfrage allein beweist deshalb noch keinen Fehler im Measure.

Zuerst das semantische Modell prüfen

Kontrolliere Beziehungen, Granularität und Spaltenumfang. Ein klares Sternschema mit Faktentabellen und Dimensionstabellen erleichtert häufig sowohl die Filterführung als auch effiziente Abfragen.

Achte besonders auf:

• ungenutzte Spalten und unnötig detaillierte Daten
• Textspalten mit sehr vielen unterschiedlichen Werten
• unnötige bidirektionale Beziehungen
• komplexe oder fachlich unklare Many-to-many-Beziehungen
• Granularitäten, die über die Anforderungen des Berichts hinausgehen

Bei Import-Modellen helfen die Modellmetriken in DAX Studio beziehungsweise VertiPaq Analyzer, große Tabellen und Spalten zu identifizieren. Entferne eine auffällige Spalte aber nicht allein wegen ihrer Größe: Prüfe zuerst ihre fachliche Verwendung und Abhängigkeiten.

Danach teure Berechnungen eingrenzen

Übernimm die Abfrage eines langsamen Visuals aus dem Performance Analyzer in DAX Studio. Server Timings und Query Plan helfen, die Arbeit von Formula Engine und Storage Engine einzuordnen.

Untersuche große Iterationen, wiederholte Auswertungen und aufwendige Filterausdrücke. Variablen können wiederholt benötigte Ergebnisse innerhalb ihres Auswertungskontexts wiederverwenden; sie sind jedoch kein pauschaler Beschleuniger. Jede Umformulierung braucht einen Laufzeitvergleich und einen Ergebnistest, insbesondere für Gesamtsummen und unterschiedliche Filterkontexte.

Was verrät der Performance Analyzer über langsame Visuals?

Der Performance Analyzer zeigt, welche Visuals Zeit für Abfragen, Darstellung und weitere Verarbeitung benötigen. Er ist ein Werkzeug zur Eingrenzung, aber kein vollständiger Nachweis der technischen Ursache.

Starte in Power BI Desktop die Aufzeichnung und führe die definierte Nutzeraktion aus. Prüfe, ob ein einzelnes Visual auffällt oder viele Visuals zusammen die Seite belasten.

Abfragezeit ist nicht gleich Darstellungszeit

Eine lange DAX-Abfrage lenkt die Untersuchung auf Modell, Berechnung und gegebenenfalls Datenquelle. Eine lange Visual-Darstellung spricht eher dafür, Datenmenge, Visual-Typ oder Komplexität der Darstellung zu prüfen. Die Kategorie „Other“ kann unter anderem Wartezeiten enthalten und sollte nicht vorschnell als Kapazitätsproblem interpretiert werden.

Da Verarbeitungsschritte parallel laufen oder aufeinander warten können, lassen sich Visual-Zeiten nicht einfach zur Seitenladezeit addieren.

Praktische Gegenproben sind:

• ein auffälliges Visual auf einer leeren Testseite isolieren
• die Anzahl dargestellter Kategorien reduzieren
• unnötige Visual-Interaktionen deaktivieren
• ein komplexes Custom Visual testweise durch ein Standardvisual ersetzen

Eine schnellere Seite hilft nur, wenn die benötigten Informationen weiterhin erreichbar bleiben.

Wann bremsen Datenquelle, Gateway oder Kapazität Power BI aus?

Bei DirectQuery kann jede Interaktion Abfragen an die Datenquelle auslösen; deren Laufzeit wirkt sich direkt auf den Bericht aus. Bei Import-Modellen betrifft die Quellleistung dagegen normalerweise die Datenaktualisierung und nicht die gewöhnliche Visual-Abfrage.

Datenquelle und Aktualisierung getrennt untersuchen

Prüfe bei DirectQuery die tatsächlich erzeugten Quellabfragen, ihre Ausführungspläne und die Auslastung der Quelle. Je nach Datenbanksystem können passende Indizes, weniger übertragene Daten oder voraggregierte Strukturen helfen. Beziehe außerdem Gateway-Ressourcen und Netzwerkwege ein, sofern ein Gateway beteiligt ist.

Bei langsamen Import-Aktualisierungen untersuchst Du stattdessen die Power-Query-Schritte. Query Diagnostics hilft bei der Analyse; Query Folding sollte dort erhalten bleiben, wo Quelle und Transformationen es unterstützen. Eine inkrementelle Aktualisierung kann den Aktualisierungsaufwand reduzieren, beschleunigt aber nicht automatisch bestehende Visual-Abfragen.

Direct Lake benötigt eine gesonderte Betrachtung: Prüfe den tatsächlichen Ausführungspfad und je nach Konfiguration mögliche DirectQuery-Fallbacks, statt pauschal Import-Verhalten anzunehmen.

Kapazität nur mit Betriebsdaten bewerten

Ist der Bericht lokal schnell, im Service aber zu bestimmten Zeiten langsam, vergleiche Lastspitzen, gleichzeitige Nutzung und Hintergrundoperationen. Für unterstützte Fabric-Kapazitäten liefert die Microsoft Fabric Capacity Metrics App Hinweise auf Auslastung, Überlastung und Drosselung.

Mehr Kapazität ist dann eine begründete Maßnahme, wenn Ressourcenengpässe nachgewiesen sind. Sie ersetzt keine Korrektur unnötig teurer Abfragen.

So gehen wir vor

Bei Ailio in Bielefeld und Hamburg trennen wir die technische Diagnose von der Entscheidung über größere Umbauten. Für einen ersten Diagnoseblock, etwa zum Abschluss Deiner Analysewoche am Freitag, strukturieren wir die Arbeit so:

Einen kritischen Ablauf messbar machen

Gemeinsam wählen wir eine fachlich relevante Nutzeraktion aus und dokumentieren Ausgangszustand, Testbedingungen und Zielgröße. Entscheidend ist die Wartezeit im Arbeitsablauf, nicht nur eine isolierte technische Kennzahl.

Hypothesen einzeln testen

Wir untersuchen das auffällige Visual, seine Abfrage und die beteiligten Komponenten. Anschließend verändern wir jeweils einen Faktor in einer Testkopie. So bleibt nachvollziehbar, welche Änderung die Verbesserung bewirkt hat.

Maßnahmen nach Wirkung priorisieren

Die Ergebnisliste enthält für jede Maßnahme:

• beobachteten Engpass und zugehörigen Messbeleg
• gemessene Verbesserung im Testszenario
• betroffene Nutzeraktionen und deren Nutzungshäufigkeit
• Umsetzungsaufwand, Risiken und offene Prüfungen
• Verantwortlichkeit und nächsten Validierungsschritt

Eine häufig verwendete Filteraktion kann dadurch Vorrang vor einer selten geöffneten Detailseite erhalten. Änderungen ohne belastbare Messung bleiben Hypothesen. Vor der Veröffentlichung prüfen wir zusätzlich fachliche Ergebnisse, Berechtigungen und das Verhalten im Service unter repräsentativer Nutzung.

Aus Messungen werden gezielte Verbesserungen

Die beste Optimierung ist nicht die technisch spektakulärste, sondern die mit nachvollziehbarer Wirkung im Berichtsalltag. Beginne mit einem klaren Testszenario und ändere nur, was Du anschließend überprüfen kannst.

Du möchtest die Engpässe Deiner bestehenden Berichte systematisch prüfen lassen? Sprich mit uns über einen weiterführenden Performance-Check im Rahmen unserer Power BI Beratung.