Risolvere i problemi comuni di prestazione

  • 6 minuti

Le singole tecniche di ottimizzazione sono preziose, ma i problemi di prestazioni reali si adattano raramente in un'unica categoria. Un report lento potrebbe avere un problema DAX, un problema di cardinalità e un problema di progettazione visiva contemporaneamente. Un approccio sistematico alla risoluzione dei problemi consente di individuare e risolvere i problemi in modo efficiente.

Seguire un flusso di lavoro di diagnosi sistematico

Quando un report è lento, usare questo approccio in tre passaggi:

  1. Si tratta della visualizzazione, del DAX o dei dati? Aprire Analizzatore prestazioni, cancellare la cache e aggiornare tutti gli oggetti visivi. Confrontare la query DAX, la visualizzazione dell'oggetto visivo e altre metriche delle tempistiche per determinare dove viene impiegato il tempo.
  2. Isolare la causa radice. Copiare la query DAX lenta ed eseguirla nella vista della query DAX. Se la query è veloce in questa posizione, ma lenta nell'oggetto visivo, il problema è il rendering. Se la query è lenta ovunque, il problema è la misura o il modello di dati.
  3. Correggere e verificare. Applicare la correzione appropriata, quindi eseguire di nuovo Analizzatore prestazioni per verificare che le prestazioni siano migliorate. Non presupporre che la correzione abbia funzionato: misurarla.

Questo flusso di lavoro (sintomo → diagnosi → correzione → verifica) impedisce di dedicare tempo al problema errato e conferma che le modifiche effettivamente aiutano.

Eseguire Best Practice Analyzer per rilevare i problemi comuni

Best Practice Analyzer (BPA) controlla il modello semantico in base a un set di più di 60 regole che coprono le prestazioni, le espressioni DAX, la prevenzione degli errori e la manutenzione. Invece di controllare manualmente ogni colonna e misura, BPA analizza l'intero modello e contrassegna i problemi relativi a colonne inutilizzate, chiavi a cardinalità elevata, descrizioni mancanti e modelli DAX inefficienti.

In Microsoft Fabric, BPA è disponibile tramite notebook di esempio che è possibile aprire direttamente dal modello semantico nel servizio Power BI. Selezionare il modello semantico, quindi scegliere il notebook BPA nella barra multifunzione Home o nell'elenco a discesa Integrità modello. Il notebook viene eseguito sul modello usando un collegamento semantico e restituisce raccomandazioni categorizzate. Un notebook di Memory Analyzer complementare mostra le statistiche di archiviazione per tabelle, colonne e relazioni.

BPA è più utile come controllo proattivo prima che si manifestino problemi di prestazione. Eseguirlo dopo la compilazione o la modifica significativa di un modello e usare i risultati per guidare le tecniche di ottimizzazione descritte in precedenza in questo modulo.

Note

Se non si ha accesso a Fabric, Editortabulare (uno strumento esterno di terze parti) include una funzionalità BPA che esegue lo stesso set di regole in locale su un modello desktop Power BI o un modello pubblicato tramite l'endpoint XMLA.

Affrontare elementi visivi complessi

Gli oggetti visivi che richiedono troppi dati sono un problema di prestazioni comune. Ogni oggetto visivo in una pagina del report invia query DAX separate al modello semantico e oggetti visivi con molte misure, punti dati o dipendenze con filtri incrociati generano query complesse.

Problemi comuni relativi alle prestazioni visive:

  • Troppe misure su una sola visuale. Un oggetto visivo tabella con 20 misure genera una query complessa molto grande. Ridurre il numero di misure o suddividere le informazioni tra più oggetti visivi.
  • Troppi punti dati. Il rendering di un grafico a dispersione con 100.000 singoli punti o una tabella con 50.000 righe richiede molto tempo. Applicare i filtri Top N per limitare le righe restituite.
  • Troppi oggetti visivi in una pagina. Ogni oggetto visivo invia query in modo indipendente. Una pagina con 30 elementi visivi esegue una query sul modello 30 volte al caricamento. Usare le pagine di drill-through e le descrizioni comando per distribuire le informazioni tra le pagine anziché riunire tutto in una pagina.

Tip

Come linea guida generale, mirare a non più di otto oggetti visivi per pagina del report. Più di questo aumenta i tempi di caricamento e rende il report più difficile da usare.

Correggere le relazioni progettate in modo non corretto

La progettazione delle relazioni influisce sul modo in cui il motore risolve la propagazione dei filtri tra tabelle. Problemi da individuare:

  • Percorsi di relazione ambigui. Più percorsi attivi tra due tabelle forzano il motore a determinare il percorso da usare, che può causare risultati imprevisti e sovraccarico delle prestazioni. Usare singole relazioni attive e USERELATIONSHIP nelle misure quando è necessario un percorso alternativo.
  • Filtro incrociato bidirezionale. Le relazioni bidirezionali propagano i filtri in entrambe le direzioni, aumentando la complessità della valutazione delle query. Usare il filtro bidirezionale solo quando necessario, ad esempio in caso di relazioni molti-a-molti.
  • Colonne di relazione di cardinalità elevata. Le relazioni sulle colonne con milioni di valori univoci (come i GUID) sono più lente da percorrere rispetto alle relazioni su colonne con cardinalità inferiore. Se possibile, usare invece chiavi surrogate intere.

Risolvere i problemi relativi al contesto di filtro

La propagazione di filtri costosa può rallentare le query anche quando la logica della misura stessa è semplice. Controllare questi modelli:

  • REMOVEFILTERS o ALL su tabelle di grandi dimensioni. Queste funzioni rimuovono il contesto di filtro, il che significa che il motore deve valutare l'intera tabella senza restrizioni. Usarli intenzionalmente e solo nell'ambito necessario.
  • Relazioni molti-a-molti con tabelle bridge di grandi dimensioni. Ogni query risolve il mapping tramite la tabella bridge. Con dati di grandi dimensioni, questo processo è costoso. Valutare se un approccio di modellazione diverso, ad esempio dimensioni con ruoli o tabelle consolidate, offre prestazioni migliori.

Risolvere i problemi relativi alle prestazioni di DirectQuery

Quando il modello semantico usa la modalità di archiviazione DirectQuery, le prestazioni lente potrebbero provenire dall'origine dati esterna anziché dal motore DAX. I problemi specifici di DirectQuery includono:

  • Errori di query folding. Power Query tenta di inviare le trasformazioni all'origine dati (query folding). Quando una trasformazione non può essere sottoposta a folding, Power BI scarica i dati non elaborati e li elabora in locale. Questo approccio è molto più lento. Esaminare la query nativa in Power Query per verificare il folding.
  • Query di origine lente. Anche quando la riduzione delle query funziona, il database di origine potrebbe eseguire la query lentamente a causa di indici mancanti, analisi di tabelle di grandi dimensioni o contesa di risorse. Collaborare con gli amministratori di database per ottimizzare le prestazioni di origine.
  • Latenza di andata e ritorno. Ogni interazione visiva invia una query all'origine dati e attende una risposta. La latenza di rete e il tempo di risposta di origine si aggiungono, in particolare nelle pagine con molti oggetti visivi. Prendere in considerazione le modalità di archiviazione miste con Importazione per i dati di riepilogo e DirectQuery per i dati di dettaglio.

Usare DAX Studio per una diagnostica più approfondita

L'analizzatore delle prestazioni e la visualizzazione query DAX gestiscono la maggior parte degli scenari di risoluzione dei problemi. Quando sono necessari dettagli a livello di motore, ad esempio se una query è bloccata nel motore delle formule o nel motore di archiviazione, DAX Studio colma il vuoto. Copiare una query DAX lenta dall'Analizzatore delle prestazioni, incollarla in DAX Studio e abilitare i tempi del server per analizzare dove viene speso esattamente il tempo. La visualizzazione Piano di query può anche rivelare operazioni inefficienti che non sono visibili solo dai dati temporali.

Note

SQL Server Profiler è un'altra opzione per acquisire una traccia completa di tutte le query DAX e DirectQuery SQL durante una sessione. Si connette all'istanza locale di Analysis Services eseguita da Power BI Desktop. Il profiler è utile per l'analisi a livello di sessione, ma per la maggior parte della risoluzione dei problemi a livello di oggetto visivo, l'analizzatore prestazioni e DAX Studio sono più pratici.

Creare un elenco di controllo per la risoluzione dei problemi

Durante l'analisi di un report lento, eseguire questi controlli nell'ordine seguente:

  1. Cancellare la cache ed eseguire Analizzatore prestazioni. Identificare l'oggetto visivo più lento e la categoria di collo di bottiglia.
  2. Se il tempo di esecuzione della query DAX è lungo, copia e analizza la query in visualizzazione query DAX o in DAX Studio. Cercare modelli costosi, ad esempio FILTER in tabelle di grandi dimensioni, iteratori o sottoespressioni ripetute.
  3. Se il tempo di visualizzazione dell'oggetto visivo è elevato, semplificare l'oggetto visivo riducendo il numero di misure, i punti dati o applicando filtri.
  4. Controllare la cardinalità delle colonne chiave. Rimuovere o ridurre le colonne a cardinalità elevata che non sono necessarie.
  5. Per i modelli DirectQuery, verificare il ripiegamento delle query e le prestazioni della sorgente.
  6. Dopo ogni modifica, misurare di nuovo per confermare il miglioramento.

Questo approccio strutturato garantisce di risolvere prima i problemi più interessati e di non dedicare tempo alle modifiche che non spostano l'ago.