Megosztás a következőn keresztül:

A Fabric API a GraphQL teljesítményével kapcsolatos ajánlott eljárásokhoz

A Microsoft Fabric API for GraphQL hatékony módot kínál az adatok hatékony lekérdezésére, de a teljesítményoptimalizálás kulcsfontosságú a zökkenőmentes és méretezhető teljesítmény biztosításához. Akár összetett lekérdezéseket kezel, akár a válaszidőt optimalizálja, az alábbi ajánlott eljárások segítenek a Legjobb teljesítmény eléréséhez a GraphQL-implementációból, és maximalizálni az API hatékonyságát a Fabricben.

Kinek van szüksége teljesítményoptimalizálásra

A teljesítményoptimalizálás kulcsfontosságú a következő célokhoz:

  • Az alkalmazásfejlesztők nagy forgalmú alkalmazásokat készítenek, amelyek a Fabric lakehouse-okat és a raktárakat kérdezik le
  • Az adatmérnökök optimalizálják a Fabric adathozzáférési mintáit nagy léptékű elemzési alkalmazásokhoz és ETL-folyamatokhoz
  • Fabric munkaterület rendszergazdái kezelik a kapacitásfelhasználást és biztosítják az erőforrások hatékony kihasználását
  • A Fabric-adatokra épülő egyéni elemzési alkalmazások válaszidejének javítása bi-fejlesztők számára
  • A DevOps-csapatok elhárítják a Fabric API-kat használó éles alkalmazások késési problémáit

Ezeket az ajánlott eljárásokat akkor használja, ha a GraphQL API-nak hatékonyan kell kezelnie az éles számítási feladatokat, vagy teljesítményproblémákat tapasztal.

Régió igazítása

A régiók közötti API-hívások gyakori oka a nagy késésnek. Az optimális teljesítmény érdekében győződjön meg arról, hogy az ügyfélalkalmazások, a Fabric-bérlő, a kapacitás és az adatforrások ugyanabban az Azure-régióban találhatók.

Ellenőrizze a bérlő régióját

A Fabric-bérlő régiójának megkeresése:

  1. Bejelentkezés a Microsoft Fabric portálra rendszergazdai fiókkal
  2. Válassza a súgó ikont (?) a jobb felső sarokban
  3. A Súgó panel alján válassza az About Fabric lehetőséget
  4. Figyelje meg a bérlő adatai között megjelenő régiót

A kapacitásrégió ellenőrzése

A GraphQL-hez készült API egy adott kapacitáson belül fut. A kapacitásrégió megkeresése:

  1. Nyissa meg azt a munkaterületet, amely a GraphQL API-t tárolja.

  2. Ugrás a Munkaterület beállításai>munkaterülettípusra

  3. A régió megkeresése a licenckapacitás alatt

    Képernyőkép a munkaterület kapacitásrégiójának lekéréséről.

Az adatforrás régiójának ellenőrzése

Az adatforrások helye a teljesítményre is hatással van:

  • Háló adatforrások (Lakehouse, Data Warehouse, SQL Database): Ezek ugyanazt a régiót használják, mint a munkaterület kapacitása
  • Külső adatforrások (Azure SQL Database stb.): Ellenőrizze az erőforrás helyét az Azure Portalon

Ajánlott eljárás: Az ügyfélalkalmazások üzembe helyezése ugyanabban a régióban, mint a Fabric-kapacitás és az adatforrások a hálózati késés minimalizálása érdekében.

Ajánlott teljesítménytesztelési eljárások

Az API teljesítményének kiértékelésekor kövesse ezeket az irányelveket a megbízható és konzisztens eredmények érdekében.

Reális teszteszközök használata

Teszteljen olyan eszközökkel, amelyek szorosan illeszkednek az éles környezethez.

  • Szkriptek vagy alkalmazások: Python-, Node.js- vagy .NET-szkriptek használata, amelyek az ügyfél tényleges viselkedését szimulálják
  • HTTP-kapcsolatkészletezés: HTTP-kapcsolatok újrafelhasználása a késés csökkentése érdekében, különösen a régiók közötti forgatókönyvek esetében fontos
  • Munkamenet-kezelés: Munkamenetek fenntartása kérések között a valós használati adatok pontos tükrözése érdekében

Mintaerőforrások:

Hasznos metrikák gyűjtése

A pontos teljesítményértékeléshez:

  1. Tesztelés automatizálása: Szkriptek vagy teljesítménytesztelő eszközök használata a tesztek konzisztens futtatásához egy meghatározott időszakban
  2. Az API bemelegítése: Több teszt lekérdezés végrehajtása a teljesítmény mérése előtt (lásd a bemelegítési követelményeket)
  3. Eloszlások elemzése: Használjon percentilisalapú metrikákat (P50, P95, P99) az átlagok helyett a késési minták megértéséhez
  4. Terhelés alatti tesztelés: Teljesítmény mérése valós egyidejű kérelemkötetekkel
  5. Dokumentumfeltételek: A napidő, a kapacitáskihasználtság és az egyidejű számítási feladatok rögzítése a tesztelés során

Gyakori teljesítményproblémák

Ezeknek a gyakori problémáknak a megismerése segít a teljesítményproblémák hatékony diagnosztizálásában és megoldásában.

Bemelegítési követelmények

Probléma: Az első API-kérés jelentősen tovább tart, mint a későbbi kérések.

Miért történik ez:

  • API-inicializálás: Tétlen állapotban az API-környezetnek inicializálnia kell az első hívás során, és hozzá kell adni néhány másodperces késést
  • Adatforrás-bemelegítés: Számos adatforrás (különösen az SQL Analytics-végpontok és adattárházak) bemelegítési fázisban van, amikor inaktív állapotba kerülnek
  • Kombinált inicializálás: Ha az API és az adatforrás is tétlen, az inicializálási idő összetett

Solution:

  • 2-3 teszt lekérdezés végrehajtása a teljesítmény mérése előtt
  • Éles alkalmazások esetén olyan állapot-ellenőrzési végpontokat implementáljon, amelyek melegen tartják az API-t
  • Fontolja meg az ütemezett lekérdezések vagy monitorozási eszközök használatát az aktív állapot munkaidőben való fenntartásához

Regionális eltérés

Probléma: Következetesen nagy késés az összes kérés esetében.

Ennek oka: A régiók közötti hálózati hívások jelentős késést eredményeznek, különösen akkor, ha az ügyfél, az API és az adatforrások különböző Azure-régiókban találhatók.

Solution:

  • Ellenőrizze, hogy az ügyfélalkalmazás, a hálókapacitás és az adatforrások ugyanabban a régióban vannak-e
  • Ha a régiók közötti hozzáférés elkerülhetetlen, alkalmazzon agresszív gyorsítótárazási stratégiákat
  • Fontolja meg regionális API-replikák üzembe helyezését globális alkalmazásokhoz

Adatforrás teljesítménye

Probléma: Az API-kérések lassúak akkor is, ha az API be van melegítve, és a régiók igazodnak.

Ennek oka: A GraphQL API lekérdezési felületként működik az adatforrások felett. Ha a mögöttes adatforrás teljesítményproblémákkal (például hiányzó indexekkel, összetett lekérdezésekkel vagy erőforrás-korlátozásokkal) rendelkezik, az API örökli ezeket a korlátozásokat.

Solution:

  1. Közvetlen tesztelés: Az adatforrás lekérdezése közvetlenül (SQL vagy más natív eszközök használatával) az alapkonfiguráció teljesítményének megállapításához
  2. Az adatforrás optimalizálása:
  3. Megfelelő méretű kapacitás: Győződjön meg arról, hogy a Fabric-kapacitás termékváltozata elegendő számítási erőforrást biztosít. A megfelelő kapacitás kiválasztásával kapcsolatos útmutatásért tekintse meg a Microsoft Fabric alapelveit .

Lekérdezések tervezése

Probléma: Egyes lekérdezések jól teljesítenek, míg mások lassúak.

Miért történik ez:

  • Túlkérés: A szükségesnél több mező kérése növeli a feldolgozási időt
  • Mély beágyazás: A többszintű beágyazott kapcsolattal rendelkező lekérdezések több feloldóvégrehajtást igényelnek
  • Hiányzó szűrők: A megfelelő szűrők nélküli lekérdezések túl sok adatot adhatnak vissza

Solution:

  • Csak a Szükséges mezők kérése a GraphQL-lekérdezésben
  • Ha lehetséges, korlátozza a beágyazott kapcsolatok mélységét
  • Megfelelő szűrők és lapozás használata a lekérdezésekben
  • Szükség esetén fontolja meg az összetett lekérdezések több egyszerűbb lekérdezésre való lebontását

Kapcsolódó tartalom

  • Last updated on