Osvedčené postupy pri výkone rozhrania GraphQL pomocou rozhrania API služby Fabric

Rozhranie API pre GraphQL služby Microsoft Fabric ponúka výkonný spôsob efektívneho dotazovania údajov, ale optimalizácia výkonu je kľúčom k zabezpečeniu plynulého a škálovateľného výkonu. Či už spracovávate zložité dotazy alebo optimalizujete časy odozvy, nasledujúce osvedčené postupy vám pomôžu získať najlepší výkon z implementácie GraphQL a maximalizovať efektivitu rozhrania API v službe Fabric.

Kto potrebuje optimalizáciu výkonu

Optimalizácia výkonu je kľúčová pre:

  • Vývojári aplikácií vytvárajú aplikácie s vysokou návštevnosťou, ktoré sa pýtajú na Fabric lakehouses a sklady
  • Dátoví inžinieri optimalizujúci vzory prístupu k dátam vo Fabric pre rozsiahle analytické aplikácie a ETL procesy
  • Administrátori pracovného priestoru fabric riadia spotrebu kapacity a zabezpečujú efektívne využívanie zdrojov
  • BI vývojári zlepšujú časy odozvy pre vlastné analytické aplikácie postavené na Fabric dátach
  • DevOps tímy riešia problémy s latenciou v produkčných aplikáciách, ktoré používajú Fabric API

Použite tieto osvedčené postupy, keď vaše GraphQL API potrebuje efektívne zvládať produkčné úlohy alebo keď máte problémy s výkonom.

Regionálne zaradenie

Medziregionálne API volania sú častou príčinou vysokej latencie. Pre optimálny výkon zabezpečte, aby vaše klientské aplikácie, Fabric tenant, kapacita a dátové zdroje boli všetky v rovnakom Azure regióne.

Skontrolujte svoj nájomný región

Na nájdenie regiónu vášho nájomcu Fabric:

  1. Prihláste sa do portálu Fabric s administrátorským účtom
  2. Vyberte ikonu Pomoc (?) v pravom hornom rohu
  3. Na spodku panelu Pomoc vyberte O látke
  4. Všimnite si región zobrazený v detailoch o nájomcovi

Skontrolujte svoju kapacitnú oblasť

Vaše API pre GraphQL beží v rámci špecifickej kapacity. Na nájdenie kapacitnej oblasti:

  1. Otvorte pracovný priestor, ktorý hostí vaše API pre GraphQL

  2. Prejdite na nastavenia >Typ pracovného priestoru

  3. Nájdite región pod kapacitou licencie

    Snímka obrazovky znázorňujúca, ako získať oblasť kapacity pre váš pracovný priestor.

Skontrolujte región zdroja dát

Umiestnenie vašich dátových zdrojov tiež ovplyvňuje výkon:

  • Fabric dátové zdroje (Lakehouse, Data Warehouse, SQL databáza): Tieto využívajú rovnakú oblasť ako kapacita pracovného priestoru
  • Externé zdroje dát (Azure SQL databáza a pod.): Skontrolujte umiestnenie zdroja v Azure portáli

Najlepšia prax: Nasadzujte klientské aplikácie v rovnakom regióne ako kapacita a dátové zdroje Fabric, aby ste minimalizovali latenciu siete.

Najlepšie postupy pri testovaní výkonu

Pri hodnotení výkonu vášho API dodržiavajte tieto odporúčania pre spoľahlivé a konzistentné výsledky.

Používajte realistické testovacie nástroje

Testujte s nástrojmi, ktoré čo najviac zodpovedajú vášmu produkčnému prostrediu:

  • Skripty alebo aplikácie: Používajte Python, Node.jsalebo .NET skripty, ktoré simulujú skutočné správanie klienta
  • HTTP pooling: Opätovné použitie HTTP spojení na zníženie latencie, čo je obzvlášť dôležité pri cross-regionálnych scenároch
  • Správa relácií: Udržiavať relácie naprieč požiadavkami tak, aby presne odrážali reálne využitie

Ukážkové zdroje:

Zbierajte zmysluplné metriky

Pre presné hodnotenie výkonu:

  1. Automatizujte testovanie: Používajte skripty alebo nástroje na testovanie výkonu na pravidelné vykonávanie testov počas definovaného obdobia
  2. Zahrievanie API: Vykonajte niekoľko testovacích dotazov pred meraním výkonu (pozri Požiadavky na zahrievanie)
  3. Analyzujte rozdelenia: Používajte metriky založené na percentiloch (P50, P95, P99) namiesto len priemerov na pochopenie vzorcov latencie
  4. Testujte pod záťažou: Merajte výkon s realistickými súbežnými objemmi požiadaviek
  5. Dokumentujte podmienky: Zaznamenávajte čas dňa, využitie kapacity a prípadné súbežné pracovné zaťaženia počas testovania

Bežné problémy s výkonom

Pochopenie týchto bežných problémov vám pomôže efektívne diagnostikovať a riešiť problémy s výkonom.

Požiadavky na rozcvičku

Problém: Prvá API požiadavka trvá výrazne dlhšie ako nasledujúce požiadavky.

Prečo sa to deje:

  • Inicializácia API: Pri nečinnosti musí API prostredie inicializovať počas prvého volania, čo pridáva niekoľko sekúnd latencie
  • Rozohrievanie zdrojov dát: Mnohé dátové zdroje (najmä SQL analytické endpointy a dátové sklady) prechádzajú fázou zahrievania, keď sú prístupné po nečinnosti
  • Kombinovaná inicializácia: Ak sú API aj dátový zdroj nečinné, časy inicializácie sa zvyšujú

Riešenie:

  • Vykonajte 2-3 testovacie dotazy pred meraním výkonu
  • Pre produkčné aplikácie implementujte endpointy na kontrolu zdravia, ktoré udržiavajú API v teple
  • Zvážte použitie plánovaných dotazov alebo monitorovacích nástrojov na udržanie aktívneho stavu počas pracovnej doby

Regionálne nesúlady

Problém: Konzistentne vysoká latencia naprieč všetkými požiadavkami.

Prečo sa to deje: Sieťové volania naprieč regiónmi pridávajú výraznú latenciu, najmä keď sú klient, API a dátové zdroje v rôznych Azure regiónoch.

Riešenie:

  • Overte, či sú vaša klientská aplikácia, kapacita Fabric a dátové zdroje v rovnakom regióne
  • Ak je prístup medzi regiónmi nevyhnutný, zavedite agresívne stratégie cache
  • Zvážte nasadenie regionálnych replík API pre globálne aplikácie

Výkon pri zdrojoch dát

Problém: API požiadavky sú pomalé aj keď je API rozohriate a regióny sú zarovnané.

Prečo sa to deje: API pre GraphQL funguje ako rozhranie na dotazy nad vašimi dátovými zdrojmi. Ak má zdrojový zdroj dát problémy s výkonom – ako chýbajúce indexy, zložité dotazy alebo obmedzenia zdrojov – API tieto obmedzenia zdedi.

Riešenie:

  1. Testujte priamo: Dotazujte sa priamo na zdroj dát (pomocou SQL alebo iných natívnych nástrojov), aby ste stanovili základný výkon
  2. Optimalizujte zdroj dát:
  3. Kapacita správnej veľkosti: Uistite sa, že váš Fabric kapacitný SKU poskytuje dostatočné výpočtové zdroje. Pozrite si Fabric koncepty pre usmernenie pri výbere vhodnej kapacity.

Návrh dotazu

Problém: Niektoré dotazy fungujú dobre, iné sú pomalé.

Prečo sa to deje:

  • Nadmerné načítavanie: Požiadavka na viac polí, než je potrebné, zvyšuje čas spracovania
  • Hlboké vnorenie: Dotazy s viacerými úrovňami vnorených vzťahov vyžadujú viacero vykonávaní resolverov
  • Chýbajúce filtre: Dotazy bez vhodných filtrov môžu vrátiť nadmerné množstvo údajov

Riešenie:

  • Požiadajte len o polia, ktoré potrebujete vo svojom GraphQL dotaze
  • Obmedziť hĺbku vnorených vzťahov, kde je to možné
  • Používajte vhodné filtre a stránkovanie vo svojich dotazoch
  • Ak je to vhodné, zvážte rozdelenie zložitých dopytov na viacero jednoduchších dopytov

Súvisiaci obsah

  • Last updated on