Udostępnij za pośrednictwem

Najlepsze praktyki dotyczące wydajności Fabric API dla GraphQL

Interfejs API usługi Microsoft Fabric dla języka GraphQL oferuje zaawansowany sposób wydajnego wykonywania zapytań o dane, ale optymalizacja wydajności jest kluczem do zapewnienia bezproblemowej i skalowalnej wydajności. Niezależnie od tego, czy obsługujesz złożone zapytania, czy optymalizujesz czasy odpowiedzi, poniższe najlepsze rozwiązania pomagają uzyskać najlepszą wydajność implementacji graphQL i zmaksymalizować wydajność interfejsu API w usłudze Fabric.

Regionów

Wywołania między regionami zazwyczaj mogą być przyczyną dużego opóźnienia. Aby osiągnąć najlepszą wydajność, zaleca się, aby klienci łączyli się z API w tym samym regionie dzierżawy i zasobów.

Region dzierżawy

Region dzierżawy można znaleźć, wykonując następujące czynności:

  1. Przejdź do portalu usługi Microsoft Fabric przy użyciu konta administratora i kliknij ikonę Pomoc ? w prawym górnym rogu.
  2. Na dole sekcji Pomoc kliknij link O Fabric.
  3. Zostaną wyświetlone szczegółowe informacje o Twoim najemcy, w tym o regionie.

Region pojemności

  1. Przejdź do portalu Microsoft Fabric, otwórz obszar roboczy, który hostuje interfejs API dla języka GraphQL.

  2. W Ustawieniach obszaru roboczego przejdź do Informacji o licencji.

  3. Informacje o regionie pojemności można znaleźć w obszarze Pojemność licencji.

    Zrzut ekranu pokazujący, jak uzyskać zakres pojemności dla obszaru roboczego.

Region źródła danych

  1. Jeśli źródło danych jest hostowane na platformie Fabric, region pojemności obszaru roboczego będzie regionem źródła danych.

  2. Jeśli źródło danych znajduje się poza platformą Sieć szkieletowa, na przykład baza danych Azure SQL Database, powinno być możliwe znalezienie informacji regionalnych w witrynie Azure Portal.

Testowanie wydajności

W przypadku klientów oceniających wydajność interfejsu API zalecamy przestrzeganie poniższych wytycznych w celu zapewnienia spójnych i niezawodnych wyników.

Narzędzia po stronie klienta

Aby emulować najbliższe zachowanie twojej aplikacji, zaleca się użycie skryptów lub demonstracyjnej aplikacji internetowej do przeprowadzenia testów i zmierzenia wydajności. Oprócz tego użycie buforowania połączeń HTTP może znacznie zmniejszyć opóźnienia, szczególnie w przypadku scenariuszy obejmujących wiele regionów.

Możesz użyć tego przykładowego skryptu testu wydajnościowego , który pomoże Ci rozpocząć pracę.

Powiązane artykuły:

Zbieranie i ocena danych

Zaleca się zautomatyzowanie wykonywania żądań w dobrze zdefiniowanym okresie przy użyciu skryptów lub narzędzi do testowania wydajności. Analizowanie średniego lub opartego na percentylu wyników pomaga zapewnić dokładniejsze i niestronne pomiary wydajności.

Typowe problemy

Oto lista typowych problemów, które mogą mieć wpływ na opóźnienie i wydajność interfejsu API.

  • Lokalizacja geograficzna klienta różni się od obszaru dzierżawcy i możliwości pojemnościowych.

    • Jeśli zamierzasz osiągnąć najlepszą wydajność aplikacji, klienci i zasoby interfejsu API w tym samym regionie pomogą osiągnąć ten cel.

  • Przeprowadź kilka zapytań do API dotyczących GraphQL przed rozpoczęciem testowania.

    • Interfejs API dla języka GraphQL nie używa ani nie pochłania jednostek pojemności (CUs), gdy jest w stanie bezczynności. Oznacza to, że środowisko interfejsu API musi być inicjowane wewnętrznie podczas pierwszego wywołania, co zajmuje kilka dodatkowych sekund. Interfejs API dla języka GraphQL ma wewnętrzne mechanizmy buforowania, które pomagają zmniejszyć opóźnienia dla wywołań ciągłych, jednak mogą wystąpić skoki opóźnień dla wywołań początkowych.
    • Poza samym interfejsem API niektóre źródła danych są znane z przechodzenia przez fazę rozgrzewki, co powoduje większe opóźnienia podczas początkowych żądań. Jeśli interfejs API uzyskuje dostęp do źródła danych, które jest również bezczynne i musi zostać zainicjowane podczas pierwszego wykonania, opóźnienie jest wyższe, ponieważ musi czekać na zainicjowanie zarówno źródła danych, jak i interfejsu API.
    • Kolejne wywołania są szybsze, ponieważ inicjowanie środowiska odbywa się tylko raz.

  • Konfiguracja źródła danych i pojemności sieci szkieletowej.

    • Interfejs API dla GraphQL można traktować jako warstwę nad źródłami danych. Jeśli samo źródło danych ma problemy z wydajnością ze względu na złożoność, oczekuje się, że opóźnienia interfejsu API mogą być wysokie. W takich przypadkach zaleca się przetestowanie zapytań dotyczących źródeł danych bezpośrednio w celu uzyskania bardziej efektywnego porównania wydajności z interfejsem API dla języka GraphQL.

    • Podczas uzyskiwania dostępu do interfejsu API GraphQL, wydajność będzie ograniczona wybraną pojemnością SKU Fabric.

Kilka czynników może mieć wpływ na wydajność interfejsu API. Zrozumienie konfiguracji źródła danych, wybranie odpowiednich regionów i efektywne mierzenie wydajności ma kluczowe znaczenie dla optymalizacji.

Treści powiązane