[object Object]

Apdex (Indeks wydajności aplikacji) to otwarty standard branżowy opracowany przez sojusz producentów oprogramowania dla przedsiębiorstw w celu pomiaru zadowolenia użytkowników z czasu reakcji aplikacji internetowych i usług IT.

Zamiast polegać wyłącznie na średnich lub percentylowych wskaźnikach czasu odpowiedzi, Apdex przekształca wskaźniki techniczne opóźnień w pojedynczy, ujednolicony wynik w zakresie od 0,0 (niedopuszczalny) do 1,0 (doskonały), który bezpośrednio odzwierciedla satysfakcję użytkownika końcowego.

Podsumowanie w pierwszej kolejności

Wynik Apdex konwertuje czasy reakcji aplikacji na pojedynczą, znormalizowaną metrykę w zakresie od 0,00 do 1,00, która mierzy satysfakcję użytkownika.Żądania są podzielone na kategorie: Zadowolone ($\le T$), Tolerujące ($> T \text{ i } \le 4T$) i Sfrustrowane (błędy $> 4T$ lub HTTP 5xx) na podstawie docelowego czasu odpowiedzi $T$ (zwykle od 200 ms do 500 ms).Formuła jest następująca: $\text {Apdex} _T = (\text {Satisfied} + (\text {Tolerating} / 2)) / \text{Łączna liczba próbek}$.Wynik Apdex powyżej 0,94 oznacza doskonałą wydajność, podczas gdy wyniki poniżej 0,70 wskazują na poważną frustrację użytkownika wymagającą natychmiastowej optymalizacji inżynieryjnej.

Jak obliczany jest wynik Apdex

Obliczenia Apdex kategoryzują każde żądanie użytkownika w jednej z trzech odrębnych stref wydajności w oparciu o zdefiniowany docelowy próg czasu odpowiedzi $T$ (taki jak 200 $\text {ms} $):

1. Zadowolony: Żądania z czasem odpowiedzi $\le T$.Użytkownicy doświadczają optymalnej reakcji i bez wahania przechodzą przez przepływy pracy.
2. Tolerowanie: Żądania z czasem odpowiedzi $> T$ i $\le 4T$.Użytkownicy zauważają niewielkie opóźnienia, ale mogą zakończyć swoje zadanie bez opuszczania aplikacji.
3. Sfrustrowany: Żądania z czasem odpowiedzi $> 4T$ lub żądania powodujące błąd HTTP (kod stanu 5xx).Użytkownicy doświadczają niedopuszczalnego spowolnienia lub całkowitej awarii usług.

Wzór matematyczny na wynik Apdex wyraża się jako:

$$\text {Apdex} _T = \frac{\text{Zadowolona liczba} + \frac{\text{Liczba tolerowana}}{2}}{\text{Łączna liczba próbek}}$$

Przepracowany przykład matematyczny

Rozważmy aplikację SaaS, która otrzymuje 10 000 żądań w ciągu godzinnego okna monitorowania z docelowym progiem $T = 200\text {ms} $:

• Zaspokojone żądania ($\le 200\text {ms} $): 8500
• Tolerowanie żądań (200 $\text {ms} < t \le 800\text {ms} $): 1000
• Sfrustrowane żądania ($> 800\text {ms} $ lub 5xx błędów): 500

Podłączenie tych wartości do wzoru Apdex daje:

$$\text {Apdex} _ {200} = \frac{8500 + \frac {1000} {2}} {10000} = \frac{8500 + 500} {10000} = \frac{9000} {10000} = 0,90$$

Wynik Apdex wynoszący 0,90 należy do kategorii Dobry, co wskazuje, że chociaż większość użytkowników cieszy się szybkim działaniem, w 15% żądań występują opóźnienia lub błędy wymagające optymalizacji.

Skala ocen i kategorie punktacji Apdex

Apdex Alliance definiuje pięć standardowych przedziałów ocen w celu przełożenia wyników liczbowych na wykonalne cele inżynieryjne:

Wybór odpowiedniego progu docelowego $T$

Wybór odpowiedniego docelowego progu $T$ ma kluczowe znaczenie dla uzyskania praktycznych wyników Apdex.Jeśli wartość $T$ jest ustawiona zbyt wysoko (na przykład $2000\text {ms} $), wolne żądania będą fałszywie klasyfikowane jako Zadowolone.I odwrotnie, jeśli wartość $T$ jest ustawiona zbyt nisko (na przykład $20\text {ms} $), normalne opóźnienie sieci niepotrzebnie obniży wynik aplikacji.

Zalecane progi docelowe według rodzaju zastosowania:

• API i mikrousługi: $T = 100\text {ms} - 200\text {ms} $
• Interaktywne aplikacje internetowe SaaS: $T = 200\text {ms} - 400\text {ms} $
• Strony produktów handlu elektronicznego: $T = 300\text {ms} - 500\text {ms} $
• Platformy multimedialne i treści: $T = 500\text {ms} - 1000\text {ms} $

Dlaczego Apdex przewyższa średni czas reakcji

Tradycyjne narzędzia monitorujące często podają średni czas reakcji.Jednak średnie mogą być bardzo mylące z następujących powodów:

1. Odstające odchylenie: Niewielka liczba skrajnych 30-sekundowych przekroczeń limitu czasu może sztucznie zawyżać średni czas odpowiedzi tysięcy szybkich żądań trwających 50 ms, powodując fałszywe alarmy.
2. Rozkłady bimodalne: Gdy aplikacja obsługuje zasoby statyczne z pamięci podręcznej w ciągu 10 ms i nie buforowane złożone zapytania do bazy danych w ciągu 2000 ms, średni czas 1005 ms nie odzwierciedla dokładnie żadnego z nich.
3. Normalizacja zorientowana na użytkownika: Apdex normalizuje wskaźniki reakcji w zrozumiały dla człowieka wynik 0 do 1, który nietechniczne strony zainteresowane, menedżerowie produktów i kadra kierownicza mogą śledzić w czasie bez konieczności posiadania głębokiej wiedzy telemetrycznej.
4. Ważenie błędów: Apdex automatycznie traktuje błędy serwera HTTP 5xx i przekroczenia limitu czasu sieci jako żądania sfrustrowane, wychwytując błędy dostępności bezpośrednio w indeksie wydajności.

Apdex a podstawowe wskaźniki internetowe (LCP i INP)

Chociaż Apdex został pierwotnie opracowany z myślą o czasach reakcji po stronie serwera i narzędziach APM, nowoczesna inżynieria wydajności sieci wymaga połączenia Apdex z Core Web Vitals firmy Google:

• Apdex: Mierzy czas odpowiedzi serwera zaplecza i opóźnienia przetwarzania API we wszystkich żądaniach HTTP.
• Największe malowanie treści (LCP): Mierzy prędkość ładowania wizualnego frontendu, gdy największy element treści kończy renderowanie w rzutni użytkownika.
• Interakcja z Next Paint (INP): Mierzy responsywność interfejsu użytkownika podczas interakcji użytkownika (kliknięcia, dotknięcia i naciśnięcia klawiszy).

Śledząc Apdex dla punktów końcowych API Go/Gin backendu wraz z LCP i INP dla aplikacji frontendowej Nuxt 4, zespoły inżynieryjne uzyskują kompleksową widoczność zarówno wydajności po stronie serwera, jak i klienta.

Integracja Apdex z przepływami pracy ciągłego monitorowania

SimpleOps automatycznie śledzi wyniki Apdex we wszystkich zarejestrowanych punktach końcowych HTTP, trasach aplikacji internetowych i mikrousługach API.Łącząc syntetyczne pingowanie sond z ponad 15 globalnych lokalizacji kontrolnych z telemetrią rzeczywistego użytkownika, SimpleOps ostrzega Twój zespół inżynierów za pośrednictwem Slack, Telegram lub Webhooks, gdy wynik Apdex Twojej aplikacji spadnie poniżej skonfigurowanego progu SLO.

Monitorując Apdex wraz z syntetycznym czasem pracy i podstawowymi wskaźnikami sieciowymi, zespoły DevOps zyskują pełny wgląd zarówno w dostępność, jak i jakość wydajności w globalnych populacjach użytkowników, zapobiegając rezygnacji klientów i chroniąc przychody biznesowe.