Condividi tramite

Migliori pratiche per le prestazioni di GraphQL nell'API Fabric

L'API di Microsoft Fabric per GraphQL offre un modo efficace per eseguire query sui dati in modo efficiente, ma l'ottimizzazione delle prestazioni è fondamentale per garantire prestazioni uniformi e scalabili. Indipendentemente dalla gestione di query complesse o dall'ottimizzazione dei tempi di risposta, le procedure consigliate seguenti consentono di ottenere prestazioni ottimali dall'implementazione di GraphQL e ottimizzare l'efficienza dell'API in Fabric.

Chi necessita dell'ottimizzazione delle prestazioni

L'ottimizzazione delle prestazioni è fondamentale per:

  • Sviluppatori di software che creano applicazioni ad alto traffico che eseguono query su lakehouse e warehouse di Fabric
  • Ingegneri dei dati che ottimizzano i modelli di accesso ai dati di Fabric per applicazioni di analisi su larga scala e processi ETL
  • Amministratori dell'area di lavoro Fabric che gestiscono il consumo di capacità e garantiscono un utilizzo efficiente delle risorse
  • Sviluppatori di business intelligence che migliorano i tempi di risposta per le applicazioni di analisi personalizzate basate sui dati di Fabric
  • I team DevOps per risolvere i problemi di latenza nelle applicazioni di produzione che utilizzano le API Fabric

Usare queste procedure consigliate quando l'API GraphQL deve gestire i carichi di lavoro di produzione in modo efficiente o quando si verificano problemi di prestazioni.

Allineamento dell'area

Le chiamate API tra aree sono una causa comune di latenza elevata. Per prestazioni ottimali, assicurati che le applicazioni client, il tenant Fabric, la capacità e le origini dati si trovino tutte nella stessa area di Azure.

Controlla la regione del tenant

Per trovare l'area del tenant di Fabric:

  1. Accedere al portale di Microsoft Fabric con un account amministratore
  2. Selezionare l'icona della Guida (?) nell'angolo in alto a destra
  3. Nella parte inferiore del riquadro della Guida selezionare Informazioni su Fabric
  4. Prendere nota della regione visualizzata nei dettagli del tenant.

Verifica la regione di capacità

L'API per GraphQL viene eseguita all'interno di una capacità specifica. Per trovare l'area della capacità:

  1. Aprire l'area di lavoro che ospita l'API per GraphQL

  2. Passare alle impostazioni >Informazioni sulla licenza

  3. Trova la regione sotto Capacità licenze

    Schermata che mostra come ottenere la regione di capacità per l'area di lavoro.

Controllare l'area dell'origine dati

Anche la posizione delle origini dati influisce sulle prestazioni:

  • Sorgenti dati dell'infrastruttura (Lakehouse, Data Warehouse, database SQL): usano la stessa area della capacità del workspace
  • Origini dati esterne (database SQL di Azure e così via): controllare il percorso della risorsa nel portale di Azure

Procedura consigliata: distribuire applicazioni client nella stessa area della capacità dell'infrastruttura e delle origini dati per ridurre al minimo la latenza di rete.

Procedure consigliate per i test delle prestazioni

Quando si valutano le prestazioni dell'API, seguire queste linee guida per ottenere risultati affidabili e coerenti.

Usare strumenti di test realistici

Eseguire il test con gli strumenti che corrispondono strettamente all'ambiente di produzione:

  • Script o applicazioni: Usare Python, Node.js o script .NET, che simulano il comportamento effettivo del client
  • Pool di connessioni HTTP: riutilizzare le connessioni HTTP per ridurre la latenza, particolarmente importante per gli scenari tra aree
  • Gestione delle sessioni: gestire le sessioni tra le richieste per riflettere in modo accurato l'utilizzo reale

Risorse di esempio:

Raccogliere metriche significative

Per una valutazione accurata delle prestazioni:

  1. Automatizzare i test: usare script o strumenti di test delle prestazioni per eseguire i test in modo coerente in un periodo definito
  2. Riscaldamento dell'API: eseguire diverse query di test prima di misurare le prestazioni (vedere Requisiti di riscaldamento)
  3. Analizzare le distribuzioni: usare le metriche basate su percentile (P50, P95, P99) anziché solo le medie per comprendere i modelli di latenza
  4. Test in fase di carico: misurare le prestazioni con volumi di richieste simultanei realistici
  5. Condizioni del documento: registrare l'ora del giorno, l'utilizzo della capacità e tutti i carichi di lavoro simultanei durante i test

Problemi comuni di prestazioni

Comprendere questi problemi comuni consente di diagnosticare e risolvere i problemi di prestazioni in modo efficace.

Requisiti di riscaldamento

Problema: la prima richiesta API richiede molto più tempo rispetto alle richieste successive.

Motivo per cui succede:

  • Inizializzazione DELL'API: quando l'ambiente API è inattivo, deve essere inizializzato durante la prima chiamata, aggiungendo alcuni secondi di latenza
  • Riscaldamento dell'origine dati: molte origini dati (in particolare endpoint di analisi SQL e data warehouse) vengono sottoposte a una fase di riscaldamento quando si accede dopo l'inattività
  • Inizializzazione combinata: se l'API e l'origine dati sono inattive, i tempi di inizializzazione sono composti

Soluzione:

  • Eseguire 2-3 query di test prima di misurare le prestazioni
  • Per le applicazioni di produzione, implementare gli endpoint di controllo dell'integrità che mantengono calda l'API
  • Considerare l'uso di query pianificate o strumenti di monitoraggio per mantenere uno stato attivo durante l'orario lavorativo

Disallineamento regionale

Problema: latenza costantemente elevata in tutte le richieste.

Perché questo accade: Le chiamate di rete tra aree aggiungono una latenza significativa, soprattutto quando il client, l'API e le origini dati si trovano in aree di Azure diverse.

Soluzione:

  • Verificare che l'applicazione client, la capacità di Fabric e le origini dati siano nella stessa area
  • Se l'accesso tra regioni è inevitabile, implementare strategie aggressive di memorizzazione nella cache.
  • Valutare la possibilità di distribuire repliche API a livello di area per applicazioni globali

Prestazioni dell'origine dati

Problema: le richieste API sono lente anche quando l'API viene riscaldata e le aree sono allineate.

Perché questo accade: L'API per GraphQL funge da interfaccia di query sulle origini dati. Se l'origine dati sottostante presenta problemi di prestazioni, ad esempio indici mancanti, query complesse o vincoli di risorse, l'API eredita tali limitazioni.

Soluzione:

  1. Eseguire direttamente il test: eseguire query direttamente sull'origine dati (usando SQL o altri strumenti nativi) per stabilire prestazioni di base
  2. Ottimizzare l'origine dati:
  3. Capacità adeguata: assicurarsi che lo SKU della capacità di Fabric fornisca risorse di calcolo sufficienti. Per indicazioni sulla selezione della capacità appropriata, vedere Concetti di Microsoft Fabric .

Progettazione di query

Problema: alcune query funzionano correttamente mentre altre sono lente.

Motivo per cui succede:

  • Over-fetching: la richiesta di più campi rispetto al necessario aumenta il tempo di elaborazione
  • Annidamento avanzato: le query con molti livelli di relazioni annidate richiedono più esecuzioni del resolver
  • Filtri mancanti: le query senza filtri appropriati possono restituire dati eccessivi

Soluzione:

  • Richiedere solo i campi necessari nella query GraphQL
  • Limitare la profondità delle relazioni annidate, dove possibile
  • Utilizzare filtri e paginazione adeguati nelle query
  • Valutare la possibilità di suddividere query complesse in più query più semplici quando appropriato

Contenuti correlati

  • Last updated on