Delen via

Best practices voor de prestaties van de Fabric API voor GraphQL

De API van Microsoft Fabric voor GraphQL biedt een krachtige manier om efficiënt query's uit te voeren op gegevens, maar prestatieoptimalisatie is essentieel om soepele en schaalbare prestaties te garanderen. Of u nu complexe query's verwerkt of reactietijden optimaliseert, de volgende aanbevolen procedures helpen u de beste prestaties te krijgen van uw GraphQL-implementatie en uw API-efficiëntie in Fabric te maximaliseren.

Wie heeft prestatieoptimalisatie nodig

Prestatieoptimalisatie is van cruciaal belang voor:

  • Toepassingsontwikkelaars bouwen toepassingen met veel verkeer die query's uitvoeren op Fabric Lakehouses en magazijnen
  • Data engineers optimaliseren Fabric-gegevensstoegangspatronen voor grootschalige analysetoepassingen en ETL-processen
  • Fabric workspace-beheerders die het capaciteitsverbruik beheren en efficiënte resourcebenutting garanderen
  • BI-ontwikkelaars verbeteren reactietijden voor aangepaste analysetoepassingen die zijn gebouwd op Fabric-gegevens
  • DevOps-teams oplossen latentieproblemen in productietoepassingen die Fabric-API's gebruiken

Gebruik deze aanbevolen procedures wanneer uw GraphQL-API productieworkloads efficiënt moet verwerken of wanneer u prestatieproblemen ondervindt.

Regio-uitlijning

API-aanroepen tussen regio's zijn een veelvoorkomende oorzaak van hoge latentie. Zorg ervoor dat uw clienttoepassingen, infrastructuurtenant, capaciteit en gegevensbronnen zich allemaal in dezelfde Azure-regio bevinden voor optimale prestaties.

Uw tenantregio controleren

Ga als volgt te werk om de regio van uw Fabric-tenant te vinden:

  1. Meld u aan bij de Microsoft Fabric-portal met een beheerdersaccount
  2. Selecteer het Help-pictogram (?) in de rechterbovenhoek
  3. Aan de onderkant van het Deelvenster Help, selecteer de optie Over Fabric
  4. Let op de regio die wordt weergegeven in de tenantdetails

Uw capaciteitsregio controleren

Uw API voor GraphQL wordt uitgevoerd binnen een specifieke capaciteit. De capaciteitsregio zoeken:

  1. Open de werkruimte die als host fungeert voor uw API voor GraphQL

  2. Ga naar Werkruimte-instellingen>Licentiegegevens

  3. De regio zoeken onder Licentiecapaciteit

    Schermopname die toont hoe je de capaciteitsregio voor je werkruimte verkrijgt.

Uw gegevensbronregio controleren

De locatie van uw gegevensbronnen heeft ook invloed op de prestaties:

  • Fabric-gegevensbronnen (Lakehouse, Data Warehouse, SQL Database): deze gebruiken dezelfde regio als de capaciteit van de werkruimte
  • Externe gegevensbronnen (Azure SQL Database, enzovoort): Controleer de resourcelocatie in Azure Portal

Best practice: Implementeer clienttoepassingen in dezelfde regio als uw Fabric-capaciteit en -gegevensbronnen om de netwerklatentie te minimaliseren.

Best practices voor prestatietests

Wanneer u de prestaties van uw API evalueert, volgt u deze richtlijnen voor betrouwbare en consistente resultaten.

Realistische testhulpprogramma's gebruiken

Test met hulpprogramma's die nauw aansluiten bij uw productieomgeving:

  • Scripts of toepassingen: Python-, Node.js- of .NET-scripts gebruiken die het werkelijke clientgedrag simuleren
  • HTTP-verbindingspooling: HTTP-verbindingen hergebruiken om de latentie te verminderen, met name belangrijk voor scenario's tussen regio's
  • Sessiebeheer: Sessies tussen aanvragen onderhouden om het werkelijke gebruik nauwkeurig weer te geven

Voorbeeldbronnen:

Zinvolle metrische gegevens verzamelen

Voor een nauwkeurige prestatiebeoordeling:

  1. Testen automatiseren: scripts of hulpprogramma's voor prestatietests gebruiken om tests consistent uit te voeren gedurende een gedefinieerde periode
  2. De API opwarmen: voer verschillende testquery's uit voordat u de prestaties meet (zie opwarmvereisten)
  3. Distributies analyseren: gebruik op percentiel gebaseerde metrische gegevens (P50, P95, P99) in plaats van alleen gemiddelden om latentiepatronen te begrijpen
  4. Testen onder belasting: Prestaties meten met realistische gelijktijdige aanvraagvolumes
  5. Documentvoorwaarden: Noteer het tijdstip van de dag, het capaciteitsgebruik en eventuele gelijktijdige workloads tijdens het testen

Veelvoorkomende prestatieproblemen

Als u deze veelvoorkomende problemen begrijpt, kunt u prestatieproblemen effectief vaststellen en oplossen.

Vereisten voor opwarmen

Probleem: de eerste API-aanvraag duurt aanzienlijk langer dan volgende aanvragen.

Waarom dit gebeurt:

  • API-initialisatie: wanneer de API-omgeving niet actief is, moet de API-omgeving tijdens de eerste aanroep initialiseren en een paar seconden latentie toevoegen
  • Opwarmen van gegevensbronnen: veel gegevensbronnen (met name SQL Analytics-eindpunten en datawarehouses) ondergaan een opwarmfase wanneer ze worden geopend nadat ze niet actief zijn
  • Gecombineerde initialisatie: Als zowel de API als de gegevensbron niet actief zijn, worden initialisatietijden samengesteld

Solution:

  • Voer 2-3 testquery's uit voordat u de prestaties meet
  • Implementeer voor productietoepassingen statuscontrole-eindpunten die de API warm houden
  • Overweeg om geplande query's of bewakingstools te gebruiken om tijdens kantooruren een actieve status te behouden.

Regionale onjuiste uitlijning

Probleem: Consistent hoge latentie voor alle aanvragen.

Waarom dit gebeurt: Netwerkoproepen tussen regio's voegen aanzienlijke latentie toe, met name wanneer de client, API en gegevensbronnen zich in verschillende Azure-regio's bevinden.

Solution:

  • Controleer of uw clienttoepassing, Fabric-capaciteit en gegevensbronnen zich in dezelfde regio bevinden
  • Als regionale toegang onvermijdelijk is, implementeert u agressieve cachingstrategieën
  • Overweeg regionale API-replica's te implementeren voor globale toepassingen

Prestaties van gegevensbron

Probleem: API-aanvragen zijn traag, zelfs wanneer de API wordt opgewarmd en regio's zijn uitgelijnd.

Waarom dit gebeurt: API voor GraphQL fungeert als een queryinterface voor uw gegevensbronnen. Als de onderliggende gegevensbron prestatieproblemen heeft, zoals ontbrekende indexen, complexe query's of resourcebeperkingen, neemt de API deze beperkingen over.

Solution:

  1. Rechtstreeks testen: rechtstreeks een query uitvoeren op de gegevensbron (met behulp van SQL of andere systeemeigen hulpprogramma's) om een basislijnprestaties tot stand te brengen
  2. De gegevensbron optimaliseren:
  3. Juiste capaciteit: zorg ervoor dat uw infrastructuurcapaciteits-SKU voldoende rekenresources biedt. Zie Microsoft Fabric-concepten voor hulp bij het selecteren van de juiste capaciteit.

Queryontwerp

Probleem: sommige query's presteren goed, terwijl andere traag zijn.

Waarom dit gebeurt:

  • Overhalen: meer velden aanvragen dan nodig is, verhoogt de verwerkingstijd
  • Diepe genesting: voor query's met veel niveaus van geneste relaties zijn meerdere resolver-uitvoeringen vereist
  • Ontbrekende filters: query's zonder de juiste filters kunnen overmatige gegevens retourneren

Solution:

  • Alleen de velden aanvragen die u nodig hebt in uw GraphQL-query
  • Beperk waar mogelijk de diepte van geneste relaties
  • De juiste filters en paginering gebruiken in uw query's
  • Overweeg complexe query's op te breken in meerdere eenvoudigere query's, indien van toepassing

Verwante inhoud

  • Last updated on