Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Microsoft Fabrics API til GraphQL tilbyder en effektiv måde at forespørge på data effektivt, men optimering af ydeevne er nøglen til at sikre en jævn og skalerbar ydeevne. Uanset om du håndterer komplekse forespørgsler eller optimerer svartider, hjælper følgende bedste praksis dig med at få den bedste ydeevne ud af din GraphQL-implementering og maksimere din API-effektivitet i Fabric.
Regioner
Opkald på tværs af områder kan generelt være årsag til høj ventetid. For at opnå den bedste ydeevne anbefales det, at klienter opretter forbindelse til API'er i samme lejer- og kapacitetsområde.
Lejerområde
Du kan finde dit lejerområde ved hjælp af følgende trin:
- Gå til Microsoft Fabric-portalen med en administratorkonto, og klik på ikonet Hjælp
?i øverste højre hjørne. - Nederst i afsnittet Hjælp skal du klikke på linket About Fabric .
- Oplysningerne om din lejer, herunder området, vises.
Kapacitetsområde
Gå til Microsoft Fabric-portalen, åbn det arbejdsområde, der er vært for din Fabric-API til GraphQL.
Gå til Licensoplysninger under Indstillinger for arbejdsområde.
Du kan finde oplysninger om dit kapacitetsområde under Licenskapacitet.
Datakildeområde
Hvis din datakilde hostes på Fabric-platformen, vil arbejdsområdets kapacitetsområde være datakildeområdet.
Hvis din datakilde er uden for Fabric-platformen, f.eks. en Azure SQL-database, bør du kunne finde de regionale oplysninger på Azure Portal.
Test af ydeevne
For kunder, der evaluerer deres API-ydeevne, anbefaler vi, at de overholder følgende retningslinjer for at sikre ensartede og pålidelige resultater.
Værktøjer på klientsiden
Hvis du vil emulere funktionsmåden for skab til dit program, anbefales det at bruge scripts eller et demowebprogram til at udføre testen for at måle ydeevnen. Derudover kan brug af HTTP-forbindelsesgruppering reducere ventetiderne betydeligt, især i forbindelse med scenarier på tværs af områder.
Du kan bruge dette eksempel på et testscript til ydeevne , der kan hjælpe dig med at komme i gang.
Relaterede artikler:
Dataindsamling og -evaluering
Det anbefales at automatisere udførelsen af anmodningen i en veldefineret tidsperiode ved hjælp af scripts eller værktøjer til test af ydeevne. Analyse af gennemsnitlige eller percentilbaserede resultater hjælper med at sikre mere nøjagtige og upartiske ydeevnemålinger.
Almindelige problemer
Her er en liste over almindelige problemer, der kan påvirke API-ventetiden og ydeevnen.
Din klients geografiske placering er forskellig fra din lejer og dit kapacitetsområde:
- Hvis du har til hensigt at opnå den bedste ydeevne for dit program, hjælper det at have klienter og API-ressourcer i det samme område med til at nå målet.
Forespørg API'en om GraphQL et par gange, før du tester:
- API til GraphQL bruger ikke kapacitet (CU'er), når den er inaktiv. Det betyder, at API-miljøet skal initialiseres internt under det første kald, hvilket tager et par ekstra sekunder. API til GraphQL har interne cachelagringsmekanismer, der hjælper med at reducere ventetider for fortløbende kald, men du kan blive udsat for ventetidsstigninger for de indledende kald.
- Ud over selve API'en er visse datakilder kendt for at gennemgå en opvarmningsfase, hvilket vil resultere i højere ventetider for indledende anmodninger. Hvis API'en får adgang til en datakilde, der også er inaktiv og tilfældigvis også skal initialiseres under den første udførelse, er ventetiden højere, fordi den skal vente initialiseringen af både datakilden og API'en.
- Efterfølgende kald er hurtigere, fordi miljøinitialiseringen kun sker én gang.
Konfiguration af datakilde og Fabric-kapacitet.
Du kan betragte API til GraphQL som en ombrydning oven på dine datakilder. Hvis selve datakilden har problemer med ydeevnen på grund af kompleksiteten, forventes det, at API-ventetiderne kan være høje. Når sådanne tilfælde opstår, anbefales det at teste forespørgsler om dine datakilder direkte for at få en mere effektiv sammenligning af ydeevnen med API'en for GraphQL.
- Følg denne vejledning i, hvordan du vælger et egnet datalager til dine forretningsbehov: Fabric-beslutningsvejledning – vælg et datalager
Når du tilgår API til GraphQL, vil ydeevnen være bundet af den Fabric-kapacitets-SKU, du har valgt.
- Se denne generelle vejledning om Fabric capacity SKU og dens beregningskraft: Microsoft Fabric-koncepter
Flere faktorer kan påvirke API-ydeevnen. Det er afgørende for optimeringen at forstå konfigurationen af din datakilde, vælge de rigtige områder og måle ydeevnen effektivt.