Share 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.

regio's

Aanroepen tussen regio's kunnen over het algemeen de oorzaak van hoge latentie zijn. Om de beste prestaties te behalen, is het raadzaam om clients te laten verbinden met API's in dezelfde tenant- en capaciteitsregio.

Tenant-regio

U vindt uw tenantregio met de volgende stappen:

  1. Ga naar de Microsoft Fabric-portal met een beheerdersaccount en klik op het Help-pictogram ? in de rechterbovenhoek.
  2. Klik onder in de Help-sectie op de koppeling Over Fabric .
  3. De details van uw tenant, inclusief de regio, worden weergegeven.

Capaciteitsregio

  1. Ga naar de Microsoft Fabric-portal en open de werkruimte die als host fungeert voor de API van uw Fabric voor GraphQL.

  2. Ga in werkruimte-instellingen naar Licentiegegevens.

  3. U vindt de informatie over uw capaciteitsregio onder Licentiecapaciteit.

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

Gegevensbronregio

  1. Als uw gegevensbron wordt gehost in het Fabric-platform, is de capaciteitsregio van de werkruimte de gegevensbronregio.

  2. Als uw gegevensbron zich buiten het Fabric-platform bevindt, bijvoorbeeld een Azure SQL-database, moet u de regionale informatie in Azure Portal kunnen vinden.

Prestatietests

Voor klanten die hun API-prestaties evalueren, raden we aan de volgende richtlijnen te volgen om consistente en betrouwbare resultaten te garanderen.

Hulpprogramma's aan de clientzijde

Als u het closetgedrag voor uw toepassing wilt emuleren, is het raadzaam om scripts of een demowebtoepassing te gebruiken om het testen uit te voeren om de prestaties te meten. Daarnaast kan het gebruik van HTTP-verbindingspooling de latenties aanzienlijk verminderen, met name voor scenario's tussen regio's.

U kunt dit voorbeeldscript voor prestatietests gebruiken waarmee u aan de slag kunt gaan.

Verwante artikelen:

Gegevensverzameling en -evaluatie

Het is raadzaam om de uitvoering van de aanvraag te automatiseren gedurende een goed gedefinieerde periode met behulp van scripts of hulpprogramma's voor prestatietests. Door de gemiddelde of percentielgebaseerde resultaten te analyseren, zorgt u voor nauwkeurigere en onbevoorbeerde prestatiemetingen.

Veelvoorkomende problemen

Hier volgt een lijst met veelvoorkomende problemen die van invloed kunnen zijn op DE API-latentie en prestaties.

  • De geografische locatie van uw client verschilt van uw tenant en capaciteitsregio:

    • Als u van plan bent om de beste prestaties voor uw toepassing te behalen, helpen clients en API-resources in dezelfde regio het doel te bereiken.

  • Voer een query uit op de API voor GraphQL voordat u gaat testen:

    • API voor GraphQL gebruikt geen capaciteit (CA's) wanneer deze niet actief is. Dit betekent dat de API-omgeving intern moet worden geïnitialiseerd tijdens de eerste aanroep. Dit duurt enkele extra seconden. API voor GraphQL heeft interne cachingmechanismen om de latentie voor continue aanroepen te verminderen, maar mogelijk ondervindt u latentiepieken voor de eerste aanroepen.
    • Afgezien van de API zelf, zijn bepaalde gegevensbronnen bekend dat ze een opwarmfase ondergaan, wat leidt tot hogere latenties voor initiële aanvragen. Als de API toegang heeft tot een gegevensbron die ook inactief is en die ook moet worden geïnitialiseerd tijdens de eerste uitvoering, is de latentie hoger omdat deze moet wachten op de initialisatie van zowel de gegevensbron als de API.
    • Volgende aanroepen zijn sneller omdat de initialisatie van de omgeving slechts eenmaal plaatsvindt.

  • Instellen van gegevensbron en fabriccapaciteit.

    • U kunt API voor GraphQL beschouwen als een wrapper boven op uw gegevensbronnen. Als uw gegevensbron zelf prestatieproblemen ondervindt vanwege de aard van de complexiteit, wordt verwacht dat DE API-latenties hoog kunnen zijn. Wanneer dergelijke gevallen optreden, is het raadzaam om uw gegevensbronnen rechtstreeks te testen voor een effectievere prestatievergelijking met die van API voor GraphQL.

    • Wanneer u de GraphQL-API opent, zijn de prestaties afhankelijk van de Fabric-capaciteits-SKU die u hebt geselecteerd.

Verschillende factoren kunnen van invloed zijn op de API-prestaties. Inzicht in de instellingen van uw gegevensbron, het selecteren van de juiste regio's en het effectief meten van de prestaties zijn cruciaal voor optimalisatie.

Verwante inhoud

  • Last updated on