Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
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.
Vem behöver prestandaoptimering
Prestandaoptimering är avgörande för:
- Programutvecklare skapar applikationer med hög trafik som kör frågor mot Fabric lakehouses och datalager
- Datatekniker optimerar infrastrukturdataåtkomstmönster för storskaliga analysprogram och ETL-processer
- Infrastrukturarbetsyteadministratörer som hanterar kapacitetsförbrukning och säkerställer effektiv resursanvändning
- BI-utvecklare förbättrar svarstiderna för anpassade analysapplikationer byggda på Fabric-data
- DevOps-team felsöker problem med svarstid i produktionsprogram som använder Infrastruktur-API:er
Använd dessa metodtips när ditt GraphQL-API behöver hantera produktionsarbetsbelastningar effektivt eller när du har prestandaproblem.
Regionjustering
API-anrop mellan regioner är en vanlig orsak till långa svarstider. För optimal prestanda, kontrollera att dina klientprogram, Fabric-klientorganisation, kapacitet och datakällor finns i samma Azure-region.
Kontrollera klientregionen
Så här hittar du Fabric-klientens region:
- Logga in på Microsoft Fabric-portalen med ett administratörskonto
- Välj hjälpikonen (?) i det övre högra hörnet
- Längst ned i hjälpfönstret väljer du Om Fabric
- Observera regionen som visas i klientinformationen
Kontrollera din kapacitetsregion
Ditt API för GraphQL körs inom en viss kapacitet. Så här hittar du kapacitetsregionen:
Öppna arbetsytan som är värd för ditt API för GraphQL
Gå till Arbetsyteinställningar>Licensinformation
Hitta regionen under Licenskapacitet
Kontrollera datakällans region
Platsen för dina datakällor påverkar också prestanda:
- Infrastrukturdatakällor (Lakehouse, Data Warehouse, SQL Database): Dessa använder samma region som arbetsytans kapacitet
- Externa datakällor (Azure SQL Database osv.): Kontrollera resursplatsen i Azure-portalen
Bästa praxis: Distribuera klientprogram i samma region som din Infrastrukturkapacitet och datakällor för att minimera nätverksfördröjningen.
Metodtips för prestandatestning
När du utvärderar api:ets prestanda följer du dessa riktlinjer för tillförlitliga och konsekventa resultat.
Använda realistiska testverktyg
Testa med verktyg som matchar produktionsmiljön på nära håll:
- Skript eller program: Använd Python-, Node.js- eller .NET-skript som simulerar verkligt klientbeteende
- HTTP-anslutningspool: Återanvänd HTTP-anslutningar för att minska svarstiden, särskilt viktigt för scenarier mellan regioner
- Sessionshantering: Underhålla sessioner mellan begäranden för att korrekt återspegla verklig användning
Exempelresurser:
- Exempel på prestandatestskript (Python Notebook)
- HTTP-sessionsobjekt i Python
- HttpClient-riktlinjer för .NET
Samla in meningsfulla mått
För korrekt prestandautvärdering:
- Automatisera testning: Använd skript eller prestandatestverktyg för att köra tester konsekvent under en definierad period
- Värm upp API:et: Kör flera testfrågor innan du mäter prestanda (se Krav för uppvärmning)
- Analysera distributioner: Använd percentilbaserade mått (P50, P95, P99) i stället för bara medelvärden för att förstå svarstidsmönster
- Test under belastning: Mät prestanda med realistiska samtidiga begärandevolymer
- Dokumentvillkor: Registrera tid på dagen, kapacitetsanvändning och eventuella samtidiga arbetsbelastningar under testningen
Andra vanliga prestandaproblem
Genom att förstå dessa vanliga problem kan du diagnostisera och lösa prestandaproblem effektivt.
Krav för uppvärmning
Problem: Den första API-begäran tar betydligt längre tid än efterföljande begäranden.
Varför händer detta:
- API-initiering: När api-miljön är inaktiv måste den initieras under det första anropet och lägga till några sekunders svarstid
- Uppvärmning av datakälla: Många datakällor (särskilt SQL Analytics-slutpunkter och informationslager) genomgår en uppvärmningsfas när de används efter att ha varit inaktiva
- Kombinerad initiering: Om både API:et och datakällan är inaktiva ökar initieringstiderna
Solution:
- Kör 2–3 testfrågor innan du mäter prestanda
- För produktionsprogram implementerar du hälsokontrollslutpunkter som håller API:et varmt
- Överväg att använda schemalagda frågor eller övervakningsverktyg för att upprätthålla ett aktivt tillstånd under kontorstid
Regional feljustering
Problem: Konsekvent hög svarstid för alla begäranden.
Varför detta händer: Nätverksanrop mellan regioner ger betydande svarstid, särskilt när klienten, API:et och datakällorna finns i olika Azure-regioner.
Solution:
- Kontrollera att klientprogrammet, infrastrukturresurserna och datakällorna finns i samma region
- Om åtkomst mellan regioner är oundviklig implementerar du aggressiva cachelagringsstrategier
- Överväg att distribuera regionala API-repliker för globala program
Prestanda för datakälla
Problem: API-begäranden är långsamma även när API:et värms upp och regionerna justeras.
Varför detta händer: API för GraphQL fungerar som ett frågegränssnitt över dina datakällor. Om den underliggande datakällan har prestandaproblem, till exempel saknade index, komplexa frågor eller resursbegränsningar, ärver API:et dessa begränsningar.
Solution:
- Testa direkt: Fråga datakällan direkt (med hjälp av SQL eller andra inbyggda verktyg) för att upprätta en baslinjeprestanda
-
Optimera datakällan:
- Lägga till lämpliga index för kolumner med vanliga frågor
- Överväg rätt datalager för ditt användningsfall: Fabricbeslutsguide – välj ett datalager
- Granska frågekörningsplaner för optimeringsmöjligheter
Rätt storlek: Se till att din SKU för Fabrickapacitet ger tillräckligt med beräkningsresurser. Mer information om hur du väljer lämplig kapacitet finns i Microsoft Fabric-begrepp .
Frågedesign
Problem: Vissa frågor fungerar bra medan andra är långsamma.
Varför händer detta:
- Överhämtning: Om du begär fler fält än nödvändigt ökar bearbetningstiden
- Djup kapsling: Förfrågningar med många nivåer av kapslade relationer kräver flera resolverkörningar.
- Filter saknas: Frågor utan lämpliga filter kan returnera överdrivna data
Solution:
- Begär endast de fält som du behöver i GraphQL-frågan
- Begränsa djupet för kapslade relationer där det är möjligt
- Använd lämpliga filter och sidnumrering i dina frågor
- Överväg att dela upp komplexa frågor i flera enklare frågor när det är lämpligt