Del via

Anbefalte fremgangsmåter for stoff-API for GraphQL-ytelse

Microsoft Fabrics API for GraphQL gir en effektiv måte å spørre data effektivt på, men ytelsesoptimalisering er nøkkelen til å sikre jevn og skalerbar ytelse. Uansett om du håndterer komplekse spørringer eller optimaliserer responstiden, kan følgende anbefalte fremgangsmåter hjelpe deg med å få best mulig ytelse ut av GraphQL-implementeringen og maksimere API-effektiviteten i Fabric.

Regioner

Samtaler på tvers av områder kan vanligvis være årsaken til høy ventetid. For å oppnå best mulig ytelse anbefales det at klienter kobler seg til API-er i samme leier- og kapasitetsområde.

Leierområde

Du finner leierområdet med følgende fremgangsmåte:

  1. Gå til Microsoft Fabric-portalen med en administratorkonto, og klikk på Hjelp-ikonet ? øverst til høyre.
  2. Klikk på Om stoff-koblingen nederst i Hjelp-delen.
  3. Detaljene om leieren, inkludert området, vises.

Kapasitetsområde

  1. Gå til Microsoft Fabric Portal, åpne arbeidsområdet som er vert for Fabric's API for GraphQL.

  2. Gå til Lisensinformasjonfra innstillinger for arbeidsområde.

  3. Du finner informasjon om kapasitetsområde under lisenskapasitet.

    Skjermbilde som viser hvordan du får kapasitetsområdet for arbeidsområdet.

Datakildeområde

  1. Hvis datakilden driftes i Fabric-plattformen, vil arbeidsområdets kapasitetsområde være datakildeområdet.

  2. Hvis datakilden er utenfor Fabric-plattformen, for eksempel en Azure SQL-database, bør du kunne finne den regionale informasjonen i Azure-portalen.

Ytelsestesting

For kunder som evaluerer API-ytelsen, anbefaler vi å følge følgende retningslinjer for å sikre konsekvente og pålitelige resultater.

Klientverktøy

Hvis du vil etterligne skapvirkemåten til programmet, anbefales det å bruke skript eller et demonettprogram til å utføre testingen for å måle ytelsen. I tillegg til dette kan bruk av HTTP-tilkoblingsutvalg i stor grad redusere ventetiden spesielt for scenarioer på tvers av områder.

Du kan bruke dette testskriptet for eksempelytelse som kan hjelpe deg med å komme i gang.

Relaterte artikler:

Datainnsamling og evaluering

Det anbefales å automatisere utføringen av forespørselen over en veldefinert tidsperiode ved hjelp av skript eller verktøy for ytelsestesting. Analyse av gjennomsnittlige eller persentilbaserte resultater bidrar til å sikre mer nøyaktige og objektive ytelsesmålinger.

Vanlige problemer

Her er en liste over vanlige problemer som kan påvirke API-ventetid og ytelse.

  • Klientens geografiske plassering er forskjellig fra tenanten og kapasitetsområdet:

    • Hvis du har tenkt å oppnå best mulig ytelse for programmet, bidrar det å ha klienter og API-ressurser i samme område til å nå målet.

  • Spør API-en for GraphQL et par ganger før testing:

    • API for GraphQL bruker ikke eller bruker ikke kapasitet (CUer) når den er inaktiv. Det betyr at API-miljøet må initialiseres internt under den første samtalen, noe som tar et par ekstra sekunder. API for GraphQL har interne hurtigbufringsmekanismer for å redusere ventetider for kontinuerlige anrop, men du kan møte ventetidstopper for de første samtalene.
    • Bortsett fra selve API-en, er visse datakilder kjent for å gjennomgå en oppvarmingsfase, noe som vil resultere i høyere ventetider for innledende forespørsler. Hvis API-en har tilgang til en datakilde som også er inaktiv, og som tilfeldigvis må initialiseres under den første kjøringen også, er ventetiden høyere fordi den må vente initialiseringen av både datakilden og API-en.
    • Etterfølgende anrop er raskere fordi miljø initialiseringen bare skjer én gang.

  • Kapasitetsrelatert oppsett for datakilde og stoff.

    • Du kan tenke på API for GraphQL som en wrapper oppå datakildene. Hvis selve datakilden har ytelsesproblemer på grunn av kompleksitetens natur, forventes det at API-ventetider kan være høye. Når slike tilfeller oppstår, anbefales det å teste spørring av datakildene direkte for en mer effektiv ytelsessammenligning med API for GraphQL.

    • Når du åpner API for GraphQL, blir ytelsen bundet av SKU-en for stoffkapasiteten du har valgt.

Flere faktorer kan påvirke API-ytelsen. Det er avgjørende å forstå datakildeoppsettet, velge de riktige områdene og måle ytelsen effektivt for optimalisering.

Relatert innhold