Strojenie wydajności aplikacji rozproszonej

  • Artykuł

W ramach tej serii artykułów przejdziemy przez kilka scenariuszy dotyczących aplikacji w chmurze, pokazując, jak zespół programistyczny użył testów obciążeniowych i metryk do diagnozowania problemów z wydajnością. Artykuły te są oparte na rzeczywistych testach obciążeniowych, które zostały wykonane podczas opracowywania przykładowych aplikacji. Kod każdego ze scenariuszy jest dostępny w witrynie GitHub.

Scenariusze:

Co to jest wydajność?

Wydajność jest często mierzona za pomocą wartości przepływności, czasu odpowiedzi i dostępności. Cele wydajności powinny opierać się na operacjach biznesowych. Zadania związane z klientem mogą mieć bardziej rygorystyczne wymagania niż zadania operacyjne, takie jak generowanie raportów.

Zdefiniuj cel poziomu usługi (SLO), który określa cele wydajności dla każdego obciążenia. Zazwyczaj ten cel można osiągnąć, dzieląc cel wydajności na zestaw kluczowych wskaźników wydajności (KPI), takich jak:

  • Opóźnienie lub czas odpowiedzi dla konkretnych żądań
  • Liczba wykonanych żądań na sekundę
  • Szybkość, z jaką system generuje wyjątki

Cele wydajności powinny jawnie obejmować obciążenie docelowe. Ponadto nie wszyscy użytkownicy otrzymują dokładnie taki sam poziom wydajności, nawet podczas uzyskiwania dostępu do systemu jednocześnie i wykonywania tej samej pracy. Dlatego cel poziomu usługi powinien być ujęty w postaci percentyli.

Przykładem celu slo może być: "Żądania klientów mają odpowiedź w ciągu 500 ms @ P90, podczas ładowania do 25 K żądań na sekundę."

Wyzwania dotyczące strojenia wydajności systemu rozproszonego

Diagnozowanie problemów z wydajnością w aplikacji rozproszonej może być szczególnie trudne. Niektóre wyzwania:

  • Pojedyncza transakcja biznesowa lub operacja zwykle obejmuje wiele składników systemu. Uzyskanie całościowego, pełnego widoku jednej operacji może być trudne.

  • Użycie zasobów jest rozłożone na wiele węzłów. Aby uzyskać spójny widok, należy zagregować dzienniki i metryki w jednym miejscu.

  • Chmura oferuje elastyczne skalowanie. Skalowanie automatyczne jest ważną techniką obsługi krótkotrwałych wzrostów obciążenia, ale może również maskować ich przyczyny. Dodatkowo określenie, które składniki należy skalować i kiedy, może być trudne.

  • Obciążenia często nie są skalowane między rdzeniami ani wątkami. Ważne jest, aby zrozumieć wymagania obciążeń i przyjrzeć się lepszym zoptymalizowanym rozmiarom. Niektóre rozmiary oferują ograniczone rdzenie i wyłączone hiperwątki, aby poprawić obciążenia licencjonowane na jedną rdzeń i na rdzeń.

  • Awarie kaskadowe mogą powodować awarie wcześniej w potoku przetwarzania, z dala od głównej przyczyny. Dlatego pierwsza oznaka problemu może pojawić się w innym składniku niż główna przyczyna.

Ogólne najlepsze praktyki

Strojenie wydajności jest zarówno sztuką, jak i nauką, ale można je zbliżyć do nauki, stosując systematyczne podejście. Oto kilka najlepszych rozwiązań:

  • Włącz telemetrię, aby zbierać metryki. Instrumentuj kod. Stosuj się do najlepszych rozwiązań dotyczących monitorowania. Używaj skorelowanego śledzenia, aby móc wyświetlić wszystkie kroki transakcji.

  • Monitoruj 90, 95 i 99 percentyl, a nie tylko średnią. Średnia może maskować wartości odstające. Częstotliwość próbkowania metryk ma także znaczenie. Jeśli częstotliwość próbkowania jest zbyt niska, może to spowodować ukrycie krótkotrwałych wzrostów lub wartości odstających, które mogą wskazywać na problemy.

  • Zajmuj się jednym wąskim gardłem na raz. Sformułuj hipotezę i przetestuj ją, zmieniając po jednej zmiennej na raz. Usunięcie jednego wąskiego gardła często powoduje odkrycie innego wąskiego gardła wcześniej lub później w potoku przetwarzania.

  • Błędy i ponowienia mogą mieć duży wpływ na wydajność. Jeśli widzisz, że usługi zaplecza ograniczają system, przeprowadź skalowanie w poziomie lub spróbuj zoptymalizować użycie (na przykład przez dostrajanie zapytań bazy danych).

  • Poszukaj typowych antywzorców wydajności.

  • Poszukaj możliwości zrównoleglenia. Dwa typowe źródła wąskich gardeł to kolejki komunikatów i bazy danych. W obu przypadkach może pomóc fragmentowanie. Aby uzyskać więcej informacji, zobacz Partycjonowanie danych w poziomie, w pionie i funkcjonalne. Poszukaj gorących partycji, które mogą wskazywać na niezrównoważone obciążenia odczytami lub zapisami.

Następne kroki

Przeczytaj scenariusze strojenia wydajności