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.

Regioni

Le chiamate tra aree possono in genere essere la causa di una latenza elevata. Per ottenere prestazioni ottimali, è consigliabile fare in modo che i client si connettino alle API nella stessa area del tenant e della capacità.

Area del tenant

È possibile trovare l'area del tenant seguendo questa procedura:

  1. Passare al portale di Microsoft Fabric con un account amministratore e fare clic sull'icona Della Guida ? nell'angolo in alto a destra.
  2. Nella parte inferiore della sezione Guida, fare clic sul collegamento Informazioni su Fabric.
  3. Vengono visualizzati i dettagli relativi al tenant, inclusa l'area.

Area della capacità

  1. Passare al portale di Microsoft Fabric, aprire l'area di lavoro che ospita l'API di Fabric per GraphQL.

  2. Dalle impostazioni dell'area di lavoro passare a Informazioni sulla licenza.

  3. È possibile trovare le informazioni della regione di capacità sotto capacità di licenza.

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

L'area di origine dei dati

  1. Se l'origine dati è ospitata nella piattaforma Fabric, l'area di capacità dell'area di lavoro sarà l'area dell'origine dati.

  2. Se l'origine dati è esterna alla piattaforma Fabric, ad esempio un database SQL di Azure, dovrebbe essere possibile trovare le informazioni a livello di area nel portale di Azure.

Test delle prestazioni

Per i clienti che valutano le prestazioni dell'API, è consigliabile attenersi alle linee guida seguenti per garantire risultati coerenti e affidabili.

Strumenti lato client

Per emulare il comportamento più vicino alla tua applicazione, si consiglia di utilizzare script o un'applicazione web demo per effettuare il test e misurare le prestazioni. Oltre a questo, l'uso del pool di connessioni HTTP può ridurre notevolmente le latenze soprattutto per gli scenari tra aree.

È possibile usare questo script di test delle prestazioni di esempio che consente di iniziare.

Articoli correlati:

Raccolta e valutazione dei dati

È consigliabile automatizzare l'esecuzione della richiesta in un periodo di tempo ben definito usando script o strumenti di test delle prestazioni. L'analisi dei risultati medi o basati su percentile consente di garantire misurazioni delle prestazioni più accurate e non distorte.

Problemi comuni

Ecco un elenco di problemi comuni che possono influire sulla latenza e sulle prestazioni dell'API.

  • La posizione geografica del client è diversa dal tenant e dall'area di capacità:

    • Se si prevede di ottenere prestazioni ottimali per l'applicazione, la disponibilità di client e risorse API nella stessa area consente di raggiungere l'obiettivo.

  • Eseguire una query sull'API per GraphQL un paio di volte prima del test:

    • L'API per GraphQL non utilizza né consuma capacità (le CU) quando è inattiva. Ciò significa che l'ambiente API deve essere inizializzato internamente durante la prima chiamata che richiede un paio di secondi aggiuntivi. L'API per GraphQL include meccanismi di memorizzazione nella cache interni per ridurre le latenze per le chiamate continue, ma è possibile che si verifichino picchi di latenza per le chiamate iniziali.
    • Oltre all'API stessa, alcune origini dati sono note per essere sottoposte a una fase di riscaldamento, che comporterà latenze più elevate per le richieste iniziali. Se l'API accede a un'origine dati che è inattiva e che deve essere inizializzata anche durante la prima esecuzione, la latenza è superiore perché deve attendere l'inizializzazione sia dell'origine dati che dell'API.
    • Le chiamate successive sono più veloci perché l'inizializzazione dell'ambiente avviene una sola volta.

  • Configurazione relativa alla fonte dei dati e alla capacità della rete.

    • È possibile pensare all'API per GraphQL come a un wrapper sopra le origini dati. Se l'origine dati stessa presenta problemi di prestazioni a causa della natura della sua complessità, è previsto che le latenze API possano essere elevate. In questi casi, è consigliabile testare direttamente l'esecuzione di query sulle origini dati per un confronto delle prestazioni più efficace con quello dell'API per GraphQL.

    • Quando si accede all'API per GraphQL, le prestazioni saranno limitate dallo SKU della capacità Fabric selezionato.

Diversi fattori possono influire sulle prestazioni dell'API. Comprendere la configurazione dell'origine dati, selezionare le aree appropriate e misurare efficacemente le prestazioni è fondamentale per l'ottimizzazione.

Contenuti correlati

  • Last updated on