Un report Power BI su Microsoft Fabric può essere lento per motivi molto diversi tra loro: una misura DAX scritta male, un modello semantico troppo largo, oppure semplicemente troppi visual sulla stessa pagina. Prima di ottimizzare a caso serve misurare, e gli strumenti per farlo sono Performance Analyzer nel Desktop e l’XMLA endpoint per le operazioni avanzate sul modello.
Performance Analyzer: separare le cause
Performance Analyzer si attiva da View → Performance Analyzer → Start recording in Power BI Desktop, poi si aggiorna la pagina (Refresh visuals). Per ogni visual registra tre contatori distinti, ed è proprio questa separazione la parte che conta:
| Contatore | Cosa misura | Se è alto, agisci su |
|---|---|---|
| DAX query | Tempo che il motore impiega a restituire il risultato | Misure, relazioni, cardinalità, modello |
| Visual display | Rendering del visual nel client | Numero di punti dati, visual custom, formattazione condizionale |
| Other | Attese, preparazione query, blocchi tra visual | Troppi visual per pagina, cross-filtering, sincronizzazione slicer |
Regola pratica: se DAX query domina, il problema è nel modello o nella misura; se domina Visual display, il problema è la quantità di elementi renderizzati (matrici enormi, custom visual pesanti); se domina Other, di solito c’è congestione perché troppi visual competono sulla stessa capacity.
Ogni riga espone Copy query, che restituisce la query DAX effettivamente generata dal visual. Quella query è il ponte verso gli strumenti esterni: incollata in DAX Studio si può eseguire con Server Timings e Query Plan attivi, ottenendo la ripartizione tra Formula Engine (single-threaded, dove finiscono iteratori e context transition costosi) e Storage Engine (VertiPaq / Direct Lake, multi-threaded e cacheable). Un rapporto sbilanciato verso il FE segnala tipicamente misure scritte con iteratori annidati o FILTER su tabelle intere invece che su colonne.
Complementare è il Best Practice Analyzer di Tabular Editor, che non misura tempi ma applica regole statiche al modello: colonne inutilizzate, relazioni bidirezionali evitabili, mancanza di IsAvailableInMdx = false su colonne non necessarie, formattazione mancante. È il controllo da eseguire prima del rilascio, mentre Performance Analyzer è il controllo a caldo sul report reale.
XMLA endpoint: cosa abilita davvero
L’XMLA endpoint espone il modello semantico di Fabric come se fosse un database Analysis Services, raggiungibile all’indirizzo powerbi://api.powerbi.com/v1.0/myorg/<workspace>.
In read consente: connessione da Excel, DAX Studio, SQL Server Profiler/traces, monitoraggio e query ad hoc.
In read/write aggiunge le operazioni che l’interfaccia web non offre:
- Deploy del modello da Tabular Editor o da script, senza ripubblicare il file
.pbix - Refresh parziale di singole tabelle o partizioni, invece del refresh completo del modello
- Scripting TMSL (
createOrReplace,refresh,alter) eseguibile da SQL Server Management Studio - Automazione via PowerShell, Tabular Object Model (TOM), Azure Automation o pipeline CI/CD
- Oggetti avanzati non editabili nel Desktop: calculation group, perspective, traduzioni, partizioni personalizzate
Prerequisiti da ricordare, tutti e tre necessari:
- Il tenant setting XMLA endpoint deve essere abilitato dall’amministratore Fabric
- Il workspace deve risiedere su una capacity (Fabric F/ Premium P / PPU): non funziona su workspace Pro condivisi
- Sull’impostazione della capacity l’endpoint va portato da Read a Read Write, e l’utente deve avere ruolo Admin, Member o Contributor sul workspace
Attenzione: un modello Direct Lake è scrivibile via XMLA, ma dopo una modifica esterna il modello può passare in stato di sola lettura per l’editing web. E il refresh di un modello Direct Lake non ricarica dati: riframa i metadati verso i file Delta più recenti.
Contromisure a un report lento
- Ridurre le colonne ad alta cardinalità: rimuovere GUID, timestamp al secondo (split in data + ora), chiavi tecniche inutilizzate. È l’intervento con il miglior rapporto sforzo/beneficio sulla compressione VertiPaq.
- Aggregare nel layer gold: pre-calcolare granularità e misure ricorrenti nel lakehouse/warehouse, così il modello legge già tabelle snelle.
- Semplificare le misure: sostituire iteratori annidati con aggregazioni native, usare
DIVIDE, evitareFILTER(Tabella, ...)a favore di filtri su colonna, ridurre le context transition. - Limitare i visual per pagina: ogni visual è almeno una query DAX; scendere sotto i circa 10-12 visual e spostare il dettaglio su drill-through o tooltip page.
- Disattivare Auto date/time e le relazioni bidirezionali non indispensabili.
Trappole tipiche d’esame
- Scenario: un visual è lento e Performance Analyzer mostra DAX query 120 ms ma Visual display 4.500 ms → Risposta giusta: il problema non è la misura; ridurre i punti dati/righe renderizzate o sostituire il custom visual, non riscrivere il DAX.
- Scenario: serve fare il deploy di un calculation group su un modello in produzione senza ripubblicare il .pbix → Risposta giusta: Tabular Editor connesso all’XMLA endpoint in read/write, previa abilitazione del tenant setting e workspace su capacity.
- Scenario: l’XMLA endpoint restituisce errore di connessione da SSMS su un workspace Pro → Risposta giusta: l’endpoint richiede una capacity (Fabric/Premium/PPU); assegnare il workspace a una capacity, non modificare i permessi utente.
- Scenario: il refresh notturno completo dura troppo, ma cambia solo la tabella Sales dell’ultimo mese → Risposta giusta: refresh parziale della partizione via TMSL/XMLA, non aumentare la capacity.
- Scenario: si vuole individuare relazioni bidirezionali e colonne inutilizzate prima del rilascio → Risposta giusta: Best Practice Analyzer di Tabular Editor, non Performance Analyzer (che misura tempi, non qualità del modello).