Analiza wydajności aplikacji: metryki, testowanie i monitorowanie

Informatec Digital » Zasoby » Analiza wydajności aplikacji: metryki, testowanie i monitorowanie

Aby osiągnąć taki poziom jakości, nie wystarczy po prostu „przetestować trochę przed publikacją”. Wymaga to połączenia ciągłego monitorowania (APM i RUM) , dobrze zaprojektowanych testów wydajności, przejrzystych metryk oraz narzędzi zdolnych do symulacji wszystkiego, od codziennego użytkowania po ekstremalne skoki ruchu. Co więcej, musi to być robione strategicznie: mierząc to, co jest naprawdę ważne dla firmy i automatyzując w jak największym stopniu, aby uniknąć ciągłego reagowania na problemy.

Wydajność aplikacji: czym jest, dlaczego jest ważna i co mierzymy

Mówiąc o wydajności aplikacji, mamy na myśli jej zdolność do szybkiego reagowania, zachowania stabilności i skalowania wraz ze wzrostem liczby użytkowników lub ilości danych, bez drastycznego zwiększania zużycia zasobów ani pogarszania jakości obsługi. Dotyczy to aplikacji mobilnych, internetowych i desktopowych , interfejsów API, mikrousług i złożonych systemów korporacyjnych.

Kluczem jest systematyczny pomiar szeregu wskaźników wydajności aplikacji (KPI) , które pozwalają zrozumieć, czy aplikacja spełnia cele techniczne i biznesowe, a także wykryć na czas, gdy coś zaczyna iść nie tak, zanim zauważy to użytkownik końcowy lub zanim w środowisku produkcyjnym włączą się alarmy.

Do najczęściej stosowanych wskaźników oceny wydajności aplikacji należą:

• użycie procesora:jak dużo mocy obliczeniowej procesora używa aplikacja i czy występują skoki napięcia wskazujące na nadmierne obliczenia, źle zaprojektowane pętle lub procesy blokujące odpowiedź.
• zużycie pamięci:objętość zajętej pamięci, pojawienie się wycieków, błędów stronicowania lub hiperstronicowania, które wskazują, że system spędza więcej czasu na przesyłaniu danych niż na wykonywaniu logiki biznesowej.
• Żądania na minutę i bajty na żądaniePokazuje, ile żądań przetwarza aplikacja lub API i ile danych obsługuje w każdym żądaniu. Pomaga to ocenić skalowalność zaplecza i upewnić się, że wolumen danych na wywołanie jest rozsądny.
• Opóźnienie i czas reakcji:czas, jaki upływa od momentu wykonania akcji przez użytkownika lub wysłania żądania przez klienta do momentu otrzymania użytecznej odpowiedzi.
• Czas sprawności i dostępność: procent czasu, w którym usługa jest uruchomiona i działa, zwykle monitorowany za pomocą cyklicznych pingów lub syntetycznych kontroli.
• Współczynnik błędów: odsetek żądań kończących się błędem (kody HTTP 4xx/5xx, nieobsłużone wyjątki, awarie funkcjonalne).
• Wynik Apdex i satysfakcja użytkownika:indeks podsumowujący w postaci jednej wartości procent zadowolonych, tolerancyjnych lub sfrustrowanych użytkowników na podstawie czasu reakcji.
• Wydajność zbiórki śmieci (GC)Na platformach z automatycznym zarządzaniem pamięcią (Java, .NET, Android), ile czasu zajmuje GC, ile wprowadza przerw i jak wpływa to na wykorzystanie procesora i płynność.
• Przepustowość lub wydajność: liczba transakcji lub żądań przetwarzanych w jednostce czasu, mająca kluczowe znaczenie w systemach o wysokiej współbieżności.

Celem śledzenia tych wskaźników nie jest tworzenie wykresów: chodzi o zrozumienie faktycznego stanu aplikacji , przewidywanie wąskich gardeł, określanie priorytetów ulepszeń i pokazanie za pomocą danych, że optymalizacje mają wpływ zarówno na doświadczenie użytkownika, jak i wyniki biznesowe.

APM, RUM i monitorowanie wydajności w czasie rzeczywistym

W nowoczesnych środowiskach z rozproszonymi architekturami, kontenerami, chmurami hybrydowymi i mikrousługami praktycznie niemożliwe jest kontrolowanie wydajności bez dobrego narzędzia do monitorowania wydajności aplikacji (APM) w połączeniu z technikami monitorowania rzeczywistych użytkowników (RUM) i, coraz częściej, zaawansowanymi komponentami umożliwiającymi obserwację.

Rozwiązania APM/RUM (takie jak rozwiązania od Elastic, Instana, Applications Manager, Turbonomic zintegrowane z APM itp.) zapewniają kompleksowy wgląd w to, co dzieje się w Twojej aplikacji: czasy reakcji, rozproszone ślady, zapytania do bazy danych, wywołania zewnętrzne, błędy i anomalie, zintegrowane z metrykami infrastruktury.

Monitorowanie rzeczywistych użytkowników (RUM) rejestruje to, co widzą prawdziwi użytkownicy: czas ładowania ekranu, zawieszanie się interfejsu, błędy przeglądarki lub aplikacji mobilnej oraz odczuwalne opóźnienia w różnych regionach i na różnych urządzeniach. Uzupełnia to syntetyczne testy porównawcze i testy laboratoryjne, które są niezbędne, ale nie zastępują danych rzeczywistych.

Z drugiej strony, nowoczesne platformy APM oferują takie funkcje jak:

• Monitorowanie na żywo Kluczowe wskaźniki KPI: dostępność, Apdex, wskaźnik błędów, prędkość transferu, Zużycie zasobów.
• Rozproszone ślady do śledzenia transakcji obejmujących wiele mikrousług, kolejek, baz danych i usług zewnętrznych, identyfikując najwolniejsze łącze.
• Mapy zależności Zautomatyzowane narzędzia pokazujące powiązania między usługami, bazami danych, kolejkami i interfejsami użytkownika, dzięki czemu łatwiej jest wykryć przyczynę awarii.
• Profilowanie kodu i wątków w celu zlokalizowania metod, zapytań SQL lub sekcji kodu, które zużywają zbyt dużo mocy procesora lub blokują wątek interfejsu.
• Inteligentne alerty i AIOps łączące uczenie maszynowe i analizę szeregów czasowych w celu wykrywania anomalii, ograniczania fałszywych alarmów i nadawania priorytetu incydentom krytycznym.

Łącząc APM, RUM i monitoring syntetyczny, zyskujesz 360-stopniowy wgląd w wydajność : co widzi użytkownik, co aplikacja robi wewnętrznie i jak reaguje infrastruktura bazowa. Pozwala to zespołom DevOps i ITOps szybko reagować na incydenty, a co więcej, zapobiegać im.

Kluczowe wskaźniki wydajności w aplikacjach mobilnych i internetowych

W aplikacjach mobilnych i internetowych niektóre wskaźniki wydajności są szczególnie wrażliwe, ponieważ bezpośrednio wpływają na postrzeganie produktu przez użytkowników i jego sukces. Uważne monitorowanie tych wskaźników decyduje o tym, czy aplikacja zachwyci użytkowników, czy zostanie odinstalowana po drugim użyciu.

Jednym z kluczowych punktów w urządzeniach mobilnych jest opóźnienie uruchomienia aplikacji , czyli czas, jaki upływa od momentu dotknięcia ikony (lub powiadomienia) przez użytkownika do momentu wyświetlenia na ekranie użytecznych danych. Można wyróżnić kilka jego rodzajów:

• Zimny ​​startAplikacja nie znajduje się w pamięci; system musi utworzyć proces, załadować kod, zainicjować biblioteki i wyświetlić pierwszy ekran.
• Półciepły startProces istnieje, ale aktywność jest odtwarzana lub przywracana do stanu pierwotnego.
• Gorący start:wystarczy, że ponownie rozszerzysz pole widzenia lub wznowisz aktywność, przy minimalnym dodatkowym wysiłku.

Dla porównania, zdecydowanie zaleca się dążenie do czasów zimnego uruchamiania poniżej 500 ms, ponieważ spowoduje to zbliżenie opóźnień p95 i p99 (najwyższe percentyle) do mediany. Jeśli niektórzy użytkownicy czekają kilka sekund, a inni otwierają aplikację w pół sekundy, coś jest nie tak.

Kolejnym krytycznym aspektem jest przewijanie i zacinanie się interfejsu . Na ruchomych ekranach (kanały, listy, galerie) użytkownicy oczekują idealnej płynności. Gdy system nie generuje klatek z częstotliwością odświeżania urządzenia (60 Hz, 90 Hz, a nawet 120 Hz), występują zacięcia i zacięcia. Te „zacięcia” występują, gdy aplikacja renderuje zawartość dłużej niż czas trwania klatki (na przykład ponad 16,7 ms przy 60 kl./s).

Oprócz płynności, należy uważnie monitorować przejścia między ekranami . Przełączanie kart, otwieranie szczegółów z listy czy wyświetlanie okien dialogowych powinno odbywać się praktycznie natychmiastowo, z płynnymi animacjami i bez migotania ani przedłużającego się pustego ekranu.

W tle, ale równie ważne, jest zużycie baterii i energooszczędność. Niepotrzebne zadania, ogromne alokacje pamięci i intensywne obciążenie procesora skracają czas pracy baterii i powodują przegrzewanie się urządzenia. Środowisko uruchomieniowe Androida (ART) poprawiło wydajność, ale jeśli wewnętrzna pętla aplikacji tworzy tysiące nowych obiektów na sekundę, koszt alokacji i czyszczenia pamięci będzie odczuwalny.

Przepływ pracy służący do identyfikowania i korygowania problemów z wydajnością

Aby uniknąć polegania na szczęściu, bardzo pomocne jest ustanowienie systematycznego procesu analizy wydajności , który łączy szczegółowe testy ręczne w laboratorium z gromadzeniem zagregowanych metryk w środowisku produkcyjnym. Typowe podejście obejmuje następujące kroki:

Najpierw należy zidentyfikować najważniejsze ścieżki użytkownika , czyli przepływy, które mają największy wpływ na doświadczenie i biznes:

• Częste uruchamianie aplikacji (ikona, powiadomienia, głębokie linki).
• Ekrany z ciągłym przewijaniem dużych ilości danych.
• Kluczowe przejścia między widokami i działaniami.
• Długie czynności, takie jak przeglądanie, odtwarzanie dźwięku/obrazu, finalizowanie transakcji itp.

Po zdefiniowaniu są one instrumentowane i analizowane za pomocą narzędzi do profilowania i śledzenia, takich jak Perfetto lub Systrace, które pozwalają sprawdzić, co robi urządzenie, z precyzją do mikrosekundy; generatorów profili pamięci, które wykrywają wycieki i punkty alokacji; lub narzędzi, takich jak Simpleperf, które pozwalają dowiedzieć się, które funkcje wykorzystują najwięcej zasobów procesora.

Należy podkreślić, że szczegółowa analiza wydajności wymaga debugowania poszczególnych przebiegów tych tras i kontrolowanego odtwarzania problemów. Analiza danych zagregowanych jest cenna w wykrywaniu wzorców i regresji, ale nie zastępuje dogłębnej analizy konkretnych śladów.

Równolegle zaleca się skonfigurowanie ciągłego gromadzenia metryk w zautomatyzowanych środowiskach testowych i w środowisku produkcyjnym: czasy uruchamiania, współczynniki blokowania, metryki klatek (na przykład za pomocą FrameMetricsAggregator na Androidzie), metryki pól w Play Console, testy porównawcze makr przewijania itp. Te metryki pozwalają zobaczyć rzeczywistą zmienność między urządzeniami, wersjami systemów operacyjnych i warunkami sieciowymi.

Ustawienia aplikacji i systemu zapewniające dokładny pomiar

Jedną z najczęstszych pułapek jest mierzenie wydajności w nierealistycznych warunkach. Aby wyniki były użyteczne, zarówno APK, jak i system muszą być starannie skonfigurowane, zapewniając środowisko testowe zbliżone do produkcyjnego, przy jednoczesnym kontrolowaniu poziomu szumów.

Po stronie aplikacji kluczowe jest, aby nie mierzyć wydajności w oparciu o kompilacje debugowe . Warianty debugowe dodają sprawdzenia, logi i flagi, które znacząco zmieniają środowisko wykonawcze. W systemie Android 10 i nowszych można użyć atrybutu `profileable android:shell="true"` w manifeście, aby umożliwić profilowanie w oparciu o kompilacje wydań, zachowując niemal realistyczne zachowanie.

Zaleca się również stosowanie redukcji kodu produkcyjnego (ProGuard, R8 itp.), ponieważ rozmiar kodu i jego organizacja znacząco wpływają na wydajność. Należy jednak zapoznać się z zasadami: niektóre konfiguracje mogą eliminować punkty śledzenia istotne dla pomiaru, które będą wymagały dostosowania w wersji testowej.

Jeśli chodzi o kompilację, warto wprowadzić aplikację w znany stan, zazwyczaj i wyraźnie określony tryb prędkości lub tryb profilu prędkości . Oba zmniejszają ilość kodu interpretowanego z DeX i potrzebę kompilacji JIT w tle, co stabilizuje wyniki. Tryb profilu prędkości stara się bardziej przypominać zachowanie w środowisku produkcyjnym, ale wymaga „rozgrzania” aplikacji i zarządzania profilami (na przykład profilami bazowymi).

Z perspektywy systemu, gdy potrzebne są pomiary o bardzo wysokiej dokładności (mikrobenchmarki), powszechną praktyką jest kalibracja urządzenia : uruchamianie testów A/B na tym samym terminalu i tej samej wersji systemu operacyjnego, ustawianie częstotliwości procesora CPU/GPU, wyłączanie małych rdzeni lub ograniczeń termicznych za pomocą skryptów, takich jak lockClocks itp. Nie odzwierciedla to rzeczywistości, ale pozwala zredukować szum w bardzo specyficznych scenariuszach.

W przypadku pomiarów bliższych doświadczeniu użytkownika (uruchamianie, zużycie baterii, zawieszanie się interfejsu użytkownika) zaleca się korzystanie z narzędzi testowych, takich jak Macrobenchmark , które automatyzują wiele z tych kroków i pozwalają uniknąć subtelnych, ale krytycznych błędów konfiguracji.

Typowe wzorce problemów z wydajnością

W prawie wszystkich aplikacjach, które zostaną dokładnie przeanalizowane, pojawiają się pewne powtarzające się wzorce problemów , o których warto wiedzieć, ponieważ jeśli zostaną wykryte na czas, zwykle udaje się znaleźć dość jasne rozwiązania.

Jednym z najczęstszych problemów jest powolne uruchamianie z powodu działania zworki . Dzieje się tak, gdy po intencji uruchomienia (ikona, powiadomienie, głęboki link) uruchamiana jest aktywność pośrednia, która nie generuje żadnych ramek, a następnie uruchamiana jest „prawdziwa” aktywność. W śladach jest to widoczne jako dwa następujące po sobie zdarzenia „activityStart” bez żadnych efektów wizualnych pomiędzy nimi. Ten „skok” wydłuża czas uruchamiania, nie dostarczając żadnej wartości. Rozwiązaniem jest zazwyczaj refaktoryzacja inicjalizacji w komponent wielokrotnego użytku lub jej bezpośrednie zintegrowanie z główną aktywnością.

Innym klasycznym przykładem są niepotrzebne alokacje, które uruchamiają odśmiecanie pamięci . Jeśli profile Systrace lub pamięci pokazują cykle GC wykonywane co kilka sekund podczas długotrwałej operacji, jest bardzo prawdopodobne, że kod wielokrotnie i stale alokuje obiekty w ramach intensywnych pętli. Rozwiązaniem nie jest usuwanie każdego nowego obiektu, ale zajęcie się punktami aktywnymi, ponowne wykorzystanie struktur lub stosowanie wzorców pulowania w razie potrzeby.

Ramki z blokowaniem często występują również w potoku graficznym . W prawidłowym śledzeniu wywołania Choreographer.doFrame() następują w regularnych odstępach czasu (na przykład co 16,7 ms). Powiększanie obszarów z taką częstotliwością może ujawnić kosztowne widoki, nadmiernie złożone układy, operacje wejścia/wyjścia uruchomione w wątku interfejsu użytkownika lub nieprawidłowo skonfigurowane obiekty RecyclerViews.

RecyclerView jest właśnie źródłem licznych problemów: unieważnia cały zbiór danych za pomocą `notifyDataSetChanged()`, gdy faktycznie zmieniło się tylko kilka elementów, niepoprawnie konfiguruje pule widoków z recyklingu w zagnieżdżonych RecyclerViews lub nie wykonuje wystarczającego wstępnego pobierania danych po dotarciu do końca listy. Wszystko to powoduje kosztowne renderowanie, przeskoki przewijania i zauważalny czas oczekiwania dla użytkownika.

Testowanie wydajności: typy, kroki i najlepsze praktyki

Poza monitorowaniem produkcji, każda poważna strategia wymaga solidnego planu testowania wydajności aplikacji w kontrolowanych środowiskach. Testowanie to pozwala zweryfikować wydajność, stabilność i skalowalność przed udostępnieniem użytkownikom zmian lub nowych wersji.

Istnieje kilka rodzajów testów, z których każdy ma swój własny, specyficzny cel:

• Testowanie obciążenioweOceniają zachowanie aplikacji przy przewidywanym obciążeniu użytkowników lub transakcji, mierząc czas reakcji, przepustowość i zużycie zasobów w celu wykrycia wąskich gardeł przed wdrożeniem.
• Testy wytrzymałościowePrzekraczają normalne granice możliwości systemu, aby sprawdzić, jak daleko można go przesunąć, jak zawodzi i jak się odbudowuje. Są kluczowi dla planowania przepustowości i zarządzania szczytami zapotrzebowania, takimi jak w Czarny Piątek.
• Testy wytrzymałościowe/moczeniaUtrzymują stałe obciążenie przez wiele godzin lub dni, aby wykryć problemy powolnej degradacji, wycieków pamięci lub wyczerpywania się zasobów.
• Testy szczytoweSymulują nagłe i powtarzające się wzrosty obciążenia (np. kampanie, wprowadzanie nowych funkcji, transmisje na żywo), aby sprawdzić, czy aplikacja i infrastruktura są w stanie poradzić sobie z nagłymi zmianami.
• Testy objętościAnalizują, jak zachowuje się aplikacja, gdy liczba użytkowników znacząco wzrasta. ilość danych (rozmiar bazy danych, pliki, wiadomości), sprawdzanie czasów reakcji, niezawodności pamięci masowej i utraty danych.
• Testy skalowalnościSprawdzają, jak aplikacja reaguje na stopniowe zwiększanie obciążenia i czy skalowanie poziome lub pionowe przynosi oczekiwaną poprawę wydajności.

Typowy proces testowania wydajności obejmuje kilka odrębnych faz. Najpierw analiza wymagań : zrozumienie, jakie czasy reakcji, wskaźniki przepustowości, poziomy dostępności i limity błędów są akceptowalne dla firmy. Następnie następuje faza planowania i strategii , w której definiowany jest zakres testów, środowisko, narzędzia i metryki do monitorowania.

Następnie projektuje się przypadki testowe obejmujące różne scenariusze obciążenia, warunki sieciowe i ilości danych. Następnie konfiguruje się środowisko testowe (sprzęt, oprogramowanie, sieć, narzędzia do generowania obciążenia i monitorowania). Następnie przeprowadza się testy, starannie zbierając dane dotyczące wydajności.

Krytyczną fazą jest monitorowanie i analiza : korelowanie czasów reakcji z wykorzystaniem procesora, opóźnień sieciowych ze współczynnikami błędów, skoków ruchu z przeciążeniem bazy danych itd. Po udokumentowaniu ustaleń w przejrzystych raportach dla interesariuszy, proces przechodzi do optymalizacji i ponownego testowania : kod, konfiguracje lub zasoby są dostosowywane, a testy są powtarzane aż do zatwierdzenia ulepszeń.

Narzędzia i struktury do testowania wydajności

Aby wdrożyć powyższe w praktyce, konieczne jest wykorzystanie specjalistycznych narzędzi do testowania wydajności , zarówno open source, jak i komercyjnych, które obejmują automatyzację, generowanie obciążenia, monitorowanie i analizę. Oto kilka istotnych kategorii:

• Narzędzia Open SourceProjekty takie jak Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder, czy też frameworki do testowania jednostkowego i funkcjonalnego (JUnit, XCTest, Appium), rozszerzone o scenariusze wydajnościowe, umożliwiają budowę bardzo wydajnych zestawów testowych przy niskich kosztach licencjonowania.
• Komercyjne narzędzia do testowania obciążenia i APMRozwiązania takie jak WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest czy Parasoft zapewniają zintegrowane środowiska z generowaniem obciążenia w chmurze, zaawansowanym raportowaniem i profesjonalnym wsparciem.
• Rozwiązania specjalistyczne i obserwowalneProdukty takie jak Applications Manager, Instana, Dynatrace, IBM Turbonomic lub platformy do monitorowania sieci, np. SolarWinds, które koncentrują się na ciągłym monitorowaniu, wykrywaniu anomalii i korelacji między wydajnością aplikacji, infrastrukturą i doświadczeniem użytkownika.
• Narzędzia specyficzne dla platformyPrzykładowo w przypadku systemu Android narzędzia takie jak Perfetto, System Tracing, Android Studio Memory Profiler, Simpleperf, Systrace czy metryki klatek konsoli Play pozwalają na bardzo szczegółową analizę zachowania na poziomie systemu.

Wybierając między jednym a drugim, warto wziąć pod uwagę takie czynniki, jak łatwość obsługi, obsługa protokołów i technologii, skalowalność, integracja z CI/CD , model licencjonowania, rozszerzalność oraz jakość wsparcia (społecznościowego lub komercyjnego). Nierzadko zdarza się również łączenie kilku: jednego do generowania obciążenia, innego do APM, a jeszcze innego do obserwowalności infrastruktury.

Krótko mówiąc, analizowanie i monitorowanie wydajności aplikacji wymaga połączenia dobrze dobranych wskaźników, właściwych narzędzi oraz dyscypliny w procesach testowania, ale wynik rekompensuje te wysiłki z nawiązką: szybsze, bardziej stabilne i wydajniejsze aplikacje , bardziej zadowoleni użytkownicy, mniej incydentów produkcyjnych i oczywiście bezpośredni pozytywny wpływ na reputację marki i przychody.

Podobne artykuły:

Odkryj Qt Creator IDE: najpotężniejsze środowisko do tworzenia aplikacji wieloplatformowych