Power BI Report langsam: Ursachen und Lösungen

Ein langsamer Power-BI-Report liegt fast immer am Datenmodell und an DAX, nicht an der Hardware: zu viele Spalten, ein fehlendes Sternschema, Felder mit hoher Kardinalität oder ineffiziente Measures zwingen die Engines von Power BI zu mehr Arbeit als nötig. Öffnen Sie zuerst den Performance Analyzer. Er zeigt, ob die Verzögerung in DAX, im Rendern der Visuals oder in der Aktualisierung liegt. Beheben Sie dann den konkreten Engpass, auf den er hinweist, statt zu raten.

Wie die Performance von Power BI funktioniert

Power BI nutzt zwei interne Engines. Die Storage Engine liest komprimierte Daten aus dem Modell und ist schnell, wenn das Modell gut gebaut ist. Die Formula Engine wertet DAX aus und wendet Filter, Aggregationen und die Logik Ihrer Measures an. Die meisten Performance-Probleme kommen aus einer von zwei Quellen: Die Formula Engine rechnet übermäßig viel, oder die Storage Engine durchsucht wegen schlechter Modellierung mehr Daten als nötig. Die Geschwindigkeit eines Reports hängt stärker vom Modelldesign ab als von Hardware oder Internetverbindung.

Die 7 häufigsten Gründe für langsame Power-BI-Reports

1. Schlechtes Datenmodell

Das Datenmodell ist der größte Einzelfaktor für die Performance. Häufige Probleme: flache Tabellen statt eines dimensionalen Modells, doppelte Daten über Tabellen hinweg, Spalten, die nie genutzt werden, und Beziehungsketten, die komplexer sind, als die Fachfrage verlangt. Power BI arbeitet am besten mit einem Sternschema, in dem Faktentabellen direkt mit Dimensionstabellen verbunden sind. Unser Leitfaden zu Best Practices der Datenmodellierung und der Leitfaden zu Sternschema vs. Snowflake Schema zeigen, auf welche Modellform Sie hinarbeiten sollten.

2. Spalten mit hoher Kardinalität

Kardinalität ist die Zahl der eindeutigen Werte in einer Spalte. Spalten mit hoher Kardinalität, etwa Transaktions-IDs, sekundengenaue Zeitstempel, GUIDs oder lange Textfelder, erhöhen den Speicherverbrauch und verlangsamen das Filtern. Unnötige Spalten mit hoher Kardinalität zu entfernen oder in Gruppen zusammenzufassen, ist oft die schnellste Einzelmaßnahme.

3. Ineffiziente DAX-Measures

Ein Measure, das die richtige Zahl liefert, liefert sie nicht immer effizient. Zeilenweises Iterieren über eine große Tabelle, eine wiederholte Berechnung innerhalb eines Measures und tief verschachtelte CALCULATE-Aufrufe zwingen die Formula Engine zu mehr Arbeit als nötig.

Dieses Margen-Measure rechnet dieselbe Subtraktion zweimal, einmal für den Test und einmal für das Ergebnis:

Margin % Unoptimized =
IF (
    [Total Sales] - [Total Cost] > 0,
    DIVIDE ( [Total Sales] - [Total Cost], [Total Sales] )
)

Mit Variablen umgeschrieben wird jeder Wert einmal berechnet, bei gleichem Ergebnis:

Margin % =
VAR SalesAmount = [Total Sales]
VAR Margin = SalesAmount - [Total Cost]
RETURN
    IF ( Margin > 0, DIVIDE ( Margin, SalesAmount ) )

VAR bedeutet auch, dass jedes Zwischenergebnis einmal berechnet und überall wiederverwendet wird, wo darauf verwiesen wird, statt jedes Mal neu berechnet zu werden. Weitere Umschreibungen wie diese finden Sie im Leitfaden zu DAX-Variablen und im Leitfaden zur DAX-Performance-Optimierung.

4. Defektes oder fehlendes Query Folding

Mit Query Folding gibt Power BI Transformationen an die Datenquelle zurück, statt sie lokal zu verarbeiten. Bricht das Folding ab, oft nach einer benutzerdefinierten Spalte oder einem nicht unterstützten Power-Query-Schritt, laufen die Transformationen in Power BI. Dann steigen Aktualisierungszeiten und Ladezeiten der Visuals.

5. Zu viele Visuals auf einer Seite

Jedes Visual sendet eine eigene Abfrage. Eine Seite mit vielen Visuals kann Dutzende Abfragen gleichzeitig auslösen, besonders wenn sich ein Slicer ändert. Als Faustregel bleibt eine Seite mit etwa 6 bis 10 Visuals meist reaktionsschnell. Die tatsächliche Zahl hängt von Ihrem Modell ab und davon, wie komplex jedes Visual ist. Verbessert sich die Ladezeit sofort, wenn Sie Visuals von einer Seite entfernen, hatte die Seite zu viele und es liegt kein Modellierungsproblem vor.

6. Der falsche Speichermodus

Power BI unterstützt Import, DirectQuery und zusammengesetzte Modelle. DirectQuery kann Latenz verursachen, weil jede Interaktion die externe Quelle direkt abfragt. Ist das Quellsystem langsam, ist es der Report auch. Wie Sie zwischen beiden wählen, steht im Leitfaden zu Import vs. DirectQuery.

7. Große Datensätze ohne Optimierung

Ein großer Datensatz ist nicht für sich das Problem, sondern ein nicht optimierter. Achten Sie auf langsame Slicer-Reaktionen, lange erste Ladezeiten und Speicherdruck bei der Aktualisierung. Power BI zu skalieren erfordert gezielte Optimierung, nicht nur den Import weiterer Zeilen.

Probleme bei Datenquelle und Aktualisierung

Bei der Geschwindigkeit eines Reports geht es nicht nur um das Modell. Eine langsame Quelldatenbank, ein überlastetes Warehouse oder eine Abfrage ohne Index können Verzögerung verursachen, noch bevor Power BI mit dem Rendern beginnt. Lange Aktualisierungszeiten bei Unternehmensquellen gehen oft auf eine Gateway-Beschränkung oder eine ineffiziente Einrichtung der inkrementellen Aktualisierung zurück und gar nicht auf Power BI.

Ein Ablauf zur Fehlersuche, Schritt für Schritt

1. Klären Sie, was tatsächlich langsam ist. Datenaktualisierung, Seitenaufbau, Interaktion mit Visuals und Slicer-Filterung haben verschiedene Ursachen. Grenzen Sie es ein, bevor Sie etwas ändern.

2. Starten Sie den Performance Analyzer. Gehen Sie in Power BI Desktop zu Ansicht > Leistungsanalyse, starten Sie die Aufzeichnung und aktualisieren Sie dann die Visuals. Er weist die Dauer der DAX-Abfrage, die Anzeigezeit des Visuals und sonstigen Mehraufwand getrennt aus. So sehen Sie, ob das Problem bei der Berechnung oder beim Rendern liegt.

3. Prüfen Sie die Modellgröße. Suchen Sie in der Modellansicht nach ungenutzten Spalten, unnötigen Tabellen, großen Textfeldern und doppelten Daten. Sie zu entfernen bringt oft sofort etwas.

4. Prüfen Sie die DAX-Measures, die der Performance Analyzer als langsam markiert hat, nach dem Umschreibemuster oben: Ersetzen Sie zeilenweise FILTER-Iteration, wo möglich, durch Variablen und eingebaute Funktionen.

5. Prüfen Sie die Beziehungen. Viele-zu-viele-Beziehungen, unnötige bidirektionale Filterung und mehrdeutige Filterpfade kosten Performance. Unser Leitfaden zu Beziehungen und Kardinalität zeigt, wie Sie sie vereinfachen.

6. Testen Sie die Komplexität der Visuals, indem Sie Visuals vorübergehend von der Seite entfernen. Verbessert sich die Performance sofort, hatte die Seite zu viele Visuals und es liegt kein Modellierungsproblem vor.

Wenn Optimierung nicht reicht

Manchmal ist die Lösung keine kleine Anpassung. Erwägen Sie, das Semantic Model umzubauen, wenn die PBIX-Datei nahe an praktischen Speichergrenzen liegt, der Report stark auf DirectQuery gegen eine langsame Quelle setzt, die Beziehungen wirklich komplex geworden sind oder die Performance-Probleme nach den obigen Schritten bleiben. Ein Umbau ist an diesem Punkt meist besser als eine weitere Runde kleiner Korrekturen.

Hilfe holen

Eine strukturierte Performance-Prüfung nach dem obigen Ablauf findet den eigentlichen Engpass schneller als Ausprobieren. Sind Ihre Reports nach diesem Leitfaden weiter langsam, liegt die Lösung in der Architektur und nicht in kleinen Korrekturen. Kontaktieren Sie CaseWhen, wenn Sie einen zweiten Blick auf ein bestimmtes Modell wünschen.

FAQs

Warum ist mein Power-BI-Report nach dem Veröffentlichen langsam?

Ein Report, der sich in Desktop gut anfühlte, kann im Service langsamer werden: wegen Kapazitätsgrenzen, DirectQuery-Latenz gegen die Live-Quelle oder weil mehr Personen gleichzeitig damit arbeiten, als Sie lokal getestet haben.

Wie viele Visuals sollte eine Power-BI-Seite enthalten?

Es gibt keine feste Zahl. Als Faustregel bleiben 6 bis 10 Visuals pro Seite meist reaktionsschnell. Eine Seite mit einfachen Karten-Visuals verträgt mehr, eine Seite mit komplexen benutzerdefinierten Visuals braucht vielleicht weniger als 6.

Beeinflusst DAX die Performance?

Ja. Ein Measure, das zeilenweise über eine große Tabelle iteriert oder dieselbe Berechnung mehrfach in sich wiederholt, zwingt die Formula Engine zu vermeidbarer Arbeit. Variablen und eingebaute Time-Intelligence-Funktionen statt manueller FILTER-Logik sind meist die schnellste Lösung.

Ist der Import-Modus schneller als DirectQuery?

In den meisten Fällen ja, weil Import aus Daten liest, die schon im Arbeitsspeicher liegen, statt bei jeder Interaktion die Quelle abzufragen. Den vollständigen Vergleich finden Sie im Leitfaden zu Import vs. DirectQuery.

Quellen

• Performance Analyzer in Power BI Desktop - Microsoft Learn