Osvědčené postupy týkající se výkonu rozhraní API fabric pro GraphQL

Rozhraní API Microsoft Fabric pro GraphQL nabízí efektivní způsob, jak efektivně dotazovat data, ale optimalizace výkonu je klíčem k zajištění hladkého a škálovatelného výkonu. Ať už zpracováváte složité dotazy nebo optimalizujete dobu odezvy, následující osvědčené postupy vám pomůžou dosáhnout nejlepšího výkonu z implementace GraphQL a maximalizovat efektivitu rozhraní API v Prostředcích infrastruktury.

Kdo potřebuje optimalizaci výkonu

Optimalizace výkonu je zásadní pro:

• Vývojáři aplikací vytvářející aplikace s vysokým provozem, které se dotazují na objekty Fabric Lakehouse a sklady
• Datoví inženýři optimalizují vzory přístupu k datům Fabric pro rozsáhlé analytické aplikace a procesy ETL
• Správci pracovního prostoru Fabric spravují spotřebu kapacity a zajišťují efektivní využití prostředků.
• Vývojáři BI vylepšují dobu odezvy pro vlastní analytické aplikace založené na datech Fabric.
• Týmy DevOps řeší problémy s latencí v produkčních aplikacích využívajících rozhraní Fabric API

Tyto osvědčené postupy použijte, když vaše rozhraní GraphQL API potřebuje efektivně zpracovávat produkční úlohy nebo když dochází k problémům s výkonem.

Zarovnání oblastí

Volání rozhraní API napříč oblastmi jsou běžnou příčinou vysoké latence. Pokud chcete dosáhnout optimálního výkonu, ujistěte se, že vaše klientské aplikace, tenant Fabric, kapacita a zdroje dat jsou ve stejném regionu Azure.

Kontrola oblasti tenanta

Chcete-li najít oblast svého Fabric tenanta:

1. Přihlaste se k portálu Microsoft Fabric pomocí účtu správce.
2. Vyberte ikonu nápovědy (?) v pravém horním rohu.
3. V dolní části podokna nápovědy vyberte O Fabricu.
4. Poznamenejte si oblast zobrazenou v podrobnostech tenanta.

Kontrola oblasti kapacity

Vaše rozhraní API pro GraphQL běží v rámci konkrétní kapacity. Vyhledání oblasti kapacity:

1. Otevření pracovního prostoru hostujícího rozhraní API pro GraphQL

2. Přejít nainformace o licenci> pracovního prostoru

3. Vyhledání oblasti v rámci kapacity licence

   

Kontrola oblasti zdroje dat

Umístění zdrojů dat má vliv také na výkon:

• Zdroje dat Fabric (Lakehouse, Data Warehouse, SQL Database): Používají tentýž región jako kapacita pracovního prostoru.
• Externí zdroje dat (Azure SQL Database atd.): Zkontrolujte umístění prostředku na webu Azure Portal.

Osvědčený postup: Nasaďte klientské aplikace ve stejné oblasti jako kapacitu služby Fabric a datové zdroje, abyste minimalizovali latenci sítě.

Osvědčené postupy pro testování výkonu

Při vyhodnocování výkonu rozhraní API postupujte podle těchto pokynů pro spolehlivé a konzistentní výsledky.

Použití realistických testovacích nástrojů

Otestujte pomocí nástrojů, které úzce odpovídají vašemu produkčnímu prostředí:

• Skripty nebo aplikace: Použití pythonu, Node.jsnebo skriptů .NET, které simulují skutečné chování klienta
• Sdružování připojení HTTP: Opakované použití připojení HTTP ke snížení latence, zejména důležité pro scénáře napříč oblastmi
• Správa relací: Udržování relací napříč požadavky tak, aby přesně odrážely skutečné využití

Ukázkové prostředky:

• Ukázkový skript testu výkonu (poznámkový blok Pythonu)
• Objekty relace HTTP v Pythonu
• Pokyny pro HttpClient pro .NET

Shromažďování smysluplných metrik

Pro přesné hodnocení výkonu:

1. Automatizace testování: Použití skriptů nebo nástrojů pro testování výkonu ke konzistentnímu spouštění testů v definovaném období
2. Zahřejte rozhraní API: Před měřením výkonu spusťte několik testovacích dotazů (viz požadavky na přípravu)
3. Analýza distribucí: Použití metrik založených na percentilu (P50, P95, P99) místo jenom průměrů k pochopení vzorců latence
4. Testování při zatížení: Měření výkonu pomocí realistických souběžných svazků požadavků
5. Podmínky dokumentu: Zaznamenávání denní doby, využití kapacity a všech souběžných úloh během testování

Běžné problémy s výkonem

Pochopení těchto běžných problémů vám pomůže efektivně diagnostikovat a řešit problémy s výkonem.

Požadavky na přípravu

Problém: První požadavek rozhraní API trvá výrazně déle než následné požadavky.

Proč se to stane:

• Inicializace rozhraní API: Při nečinnosti musí prostředí rozhraní API inicializovat během prvního volání a přidat několik sekund latence.
• Zahřátí zdroje dat: Mnoho zdrojů dat (zejména koncových bodů SQL Analytics a datových skladů) prochází po nečinnosti fázi zahřátí.
• Kombinovaná inicializace: Pokud jsou rozhraní API i zdroj dat nečinné, inicializační časy se sčítají.

Solution:

• Před měřením výkonu spusťte 2 až 3 testovací dotazy.
• V produkčních aplikacích implementujte koncové body kontroly stavu, které udržují rozhraní API v teplém stavu.
• Zvažte použití plánovaných dotazů nebo monitorovacích nástrojů k udržování aktivního stavu během pracovní doby.

Regionální chybné zarovnání

Problém: Konzistentně vysoká latence napříč všemi požadavky

Proč k tomu dochází: Síťová volání mezi oblastmi přidávají významnou latenci, zejména pokud jsou klient, rozhraní API a zdroje dat v různých oblastech Azure.

Solution:

• Ověřte, že klientská aplikace, kapacita Fabric a zdroje dat jsou ve stejném regiónu.
• Pokud je přístup mezi oblastmi nevyhnutelný, implementujte agresivní strategie cache.
• Zvažte nasazení replik regionálního rozhraní API pro globální aplikace.

Výkon zdroje dat

Problém: Požadavky rozhraní API jsou pomalé i v případě, že se rozhraní API zahřeje a oblasti jsou zarovnané.

Proč k tomu dochází: Rozhraní API pro GraphQL funguje jako dotazovací rozhraní pro vaše zdroje dat. Pokud má podkladový zdroj dat problémy s výkonem , jako jsou chybějící indexy, složité dotazy nebo omezení prostředků, rozhraní API tato omezení dědí.

Solution:

1. Přímé testování: Dotazování zdroje dat přímo (pomocí SQL nebo jiných nativních nástrojů) za účelem vytvoření základního výkonu
2. Optimalizace zdroje dat:
   • Přidání vhodných indexů pro často dotazované sloupce
   • Zvažte správné úložiště dat pro váš případ použití: Průvodce rozhodováním o prostředcích infrastruktury – volba úložiště dat
   • Kontrola plánů provádění dotazů pro příležitosti optimalizace
3. Správná kapacita: Ujistěte se, že kapacitní SKU Fabric poskytuje dostatečné výpočetní prostředky. Pokyny k výběru vhodné kapacity najdete v konceptech Microsoft Fabric .

Návrh dotazu

Problém: Některé dotazy fungují dobře, zatímco jiné jsou pomalé.

Proč se to stane:

• Over-fetching: Vyžádání více polí, než je potřeba, zvyšuje dobu zpracování.
• Hluboké vnoření: Dotazy s mnoha úrovněmi vnořených relací vyžadují více spuštění resolveru.
• Chybějící filtry: Dotazy bez odpovídajících filtrů můžou vracet nadměrná data.

Solution:

• Vyžádání pouze potřebných polí v dotazu GraphQL
• Pokud je to možné, omezte hloubku vnořených relací.
• Použití vhodných filtrů a stránkování v dotazech
• Zvažte rozdělení složitých dotazů do několika jednodušších dotazů, pokud je to vhodné.

Související obsah

• Přehled rozhraní API fabric pro GraphQL
• Rozhraní API fabric pro editor GraphQL