Metodtips för fabric API för GraphQL-prestanda

Microsoft Fabrics API för GraphQL erbjuder ett kraftfullt sätt att köra frågor mot data effektivt, men prestandaoptimering är nyckeln till att säkerställa smidig och skalbar prestanda. Oavsett om du hanterar komplexa frågor eller optimerar svarstiderna hjälper följande metodtips dig att få ut bästa möjliga prestanda av GraphQL-implementeringen och maximera API-effektiviteten i Fabric.

Regioner

Anrop mellan regioner kan vanligtvis orsaka långa svarstider. För att uppnå bästa prestanda rekommenderar vi att klienter ansluter till API:er i samma klient- och kapacitetsregion.

Klientregion

Du hittar din klientregion med följande steg:

1. Gå till Microsoft Fabric-portalen med ett administratörskonto och klicka på hjälpikonen ? i det övre högra hörnet.
2. Klicka på länken Om Fabric längst ned i hjälpavsnittet.
3. Informationen om din hyresgäst, inklusive region, visas.

Kapacitetsregion

1. Gå till Microsoft Fabric-portalen och öppna arbetsytan som är värd för infrastrukturresursens API för GraphQL.

2. Från Arbetsyteinställningar går du till Licensinformation.

3. Du hittar information om din kapacitetsregion under Licenskapacitet.

   

Datakällans region

1. Om datakällan finns i Infrastrukturplattformen är arbetsytans kapacitetsregion datakällans region.

2. Om din datakälla ligger utanför Fabric-plattformen, till exempel en Azure SQL-databas, bör du kunna hitta den regionala informationen i Azure-portalen.

Prestandatestning

För kunder som utvärderar sina API-prestanda rekommenderar vi att du följer följande riktlinjer för att säkerställa konsekventa och tillförlitliga resultat.

Verktyg på klientsidan

För att emulera det närmast möjliga beteendet för din applikation rekommenderar vi att du använder skript eller en demo-webbapplikation för att genomföra testerna och mäta prestanda. Dessutom kan användningen av HTTP-anslutningspooler avsevärt minska svarstiderna, särskilt för scenarier mellan regioner.

Du kan använda det här exempelskriptet för prestandatest som kan hjälpa dig att komma igång.

Relaterade artiklar:

• Avancerad användning – Dokumentation om begäranden 2.32.3

• HttpClient-riktlinjer för .NET

Insamling och utvärdering av data

Vi rekommenderar att du automatiserar körningen av begäranden under en väldefinierad tidsperiod med hjälp av skript eller verktyg för prestandatestning. Genom att analysera genomsnittliga eller percentilbaserade resultat kan du säkerställa mer exakta och opartiska prestandamätningar.

Vanliga problem

Här är en lista över vanliga problem som kan påverka API-svarstid och prestanda.

• Klientens geo-plats skiljer sig från klient- och kapacitetsregionen:

  • Om du vill uppnå bästa möjliga prestanda för ditt program kan du uppnå målet genom att ha klienter och API-resurser i samma region.

• Fråga API:et för GraphQL ett par gånger innan du testar:

  • API för GraphQL använder inte eller förbrukar kapacitet (CUS) när det är inaktivt. Det innebär att API-miljön måste initieras internt under det första anropet, vilket tar några extra sekunder. API för GraphQL har interna cachelagringsmekanismer för att minska svarstiderna för kontinuerliga anrop, men du kan drabbas av svarstidstoppar för de första anropen.
  • Förutom själva API:et är vissa datakällor kända för att genomgå en uppvärmningsfas, vilket resulterar i högre svarstider för inledande begäranden. Om API:et har åtkomst till en datakälla som också är inaktiv och råkar behöva initieras under den första körningen är svarstiden högre eftersom den måste vänta på initieringen av både datakällan och API:et.
  • Efterföljande anrop går snabbare eftersom miljöinitieringen bara sker en gång.

• Relaterad inställning av datakälla och serverkapacitet.

  • Du kan se API för GraphQL som en omslutning ovanpå dina datakällor. Om själva datakällan har prestandaproblem på grund av komplexiteten förväntas API-svarstiderna vara höga. När sådana fall inträffar rekommenderar vi att du testar att fråga dina datakällor direkt för en effektivare prestandajämförelse med API:et för GraphQL.

    • Följ den här guiden om hur du väljer ett lämpligt datalager för dina affärsbehov: Vägledning för plattformsbeslut – välj ett datalager

  • Vid åtkomst till API för GraphQL kommer prestandan att bindas av den SKU för infrastrukturkapacitet som du har valt.

    • Referera till den här allmänna vägledningen om Fabric-kapacitets-SKU:n och dess beräkningskapacitet: Microsoft Fabric-begrepp

Flera faktorer kan påverka API-prestanda. Att förstå konfigurationen av datakällan, välja rätt regioner och effektivt mäta prestanda är avgörande för optimering.

Relaterat innehåll

• Översikt över Infrastruktur-API för GraphQL
• Infrastruktur-API för GraphQL-redigeraren