load testing serwera

Load testing serwera to badanie zachowania systemu przy zadanym obciążeniu w celu wyznaczenia jego granic.

Na czym polega obciążeniowe badanie serwera

Load testing serwera, czyli testowanie obciążeniowe, polega na kontrolowanym generowaniu ruchu odpowiadającego określonemu sposobowi używania systemu. Test może obejmować żądania HTTP i HTTPS, połączenia TCP, zapytania do usługi aplikacyjnej albo inne operacje obsługiwane przez badany serwer. Celem jest sprawdzenie, jak system zachowuje się przy założonej liczbie równoczesnych użytkowników, żądań na sekundę lub wykonywanych transakcji. Nie chodzi wyłącznie o doprowadzenie serwera do awarii, lecz o ustalenie, czy przy przewidywanym obciążeniu zachowuje wymagany czas odpowiedzi, przepustowość i poprawność działania.

Scenariusz testu powinien odwzorowywać rzeczywisty profil ruchu. Może zawierać na przykład logowanie, wyszukiwanie, odczyt danych, zapis formularza i wylogowanie, przy czym każda operacja może mieć inny udział w całkowitej liczbie żądań. Ważne są również przerwy między operacjami, liczba użytkowników wirtualnych, czas narastania obciążenia oraz długość fazy stabilnego ruchu. Jednorazowe wysłanie dużej liczby żądań nie zastępuje testu obciążeniowego, ponieważ nie pokazuje zachowania systemu podczas stopniowego dochodzenia do normalnego poziomu pracy.

Przepustowość, opóźnienia i punkt nasycenia

Podczas testu rejestruje się przede wszystkim przepustowość oraz opóźnienie odpowiedzi. Przepustowość może być wyrażana jako liczba żądań na sekundę, transakcji na sekundę albo zakończonych operacji w jednostce czasu. Sam średni czas odpowiedzi jest niewystarczający, ponieważ kilka bardzo wolnych żądań może zostać ukrytych przez wiele szybkich odpowiedzi. Dlatego analizuje się percentyle, na przykład p95 i p99. Wartość p95 oznacza czas, poniżej którego zakończyło się 95 procent obserwowanych operacji, a p99 opisuje granicę dla 99 procent operacji.

Punkt nasycenia pojawia się wtedy, gdy dalsze zwiększanie ruchu nie daje proporcjonalnego wzrostu przepustowości, a opóźnienia i liczba błędów zaczynają rosnąć. Przyczyną może być wyczerpanie czasu procesora, pamięci operacyjnej, przepustowości dysku lub interfejsu sieciowego. Ograniczeniem może być także pula połączeń, liczba wątków, kolejka zadań, limit deskryptorów plików albo zewnętrzna usługa wywoływana przez aplikację. Wynik testu powinien wskazywać obciążenie, przy którym wymagania są jeszcze spełnione, oraz poziom, przy którym występuje degradacja jakości.

Budowa scenariusza i obserwacja zasobów

Przygotowanie testu rozpoczyna się od określenia modelu ruchu i kryteriów akceptacji. Należy ustalić między innymi liczbę równoczesnych sesji, oczekiwaną przepustowość, dopuszczalny odsetek błędów oraz graniczne wartości opóźnienia. Testy narzędziami takimi jak Apache JMeter, Gatling, k6 lub wrk powinny być wykonywane z odpowiednio wydajnego generatora ruchu, ponieważ generator może stać się wąskim gardłem i zaniżyć wynik. Dla żądań HTTPS trzeba uwzględnić koszt zestawiania połączeń TLS, chyba że scenariusz celowo korzysta z utrzymywanych połączeń. Należy także rozróżnić ruch odczytowy i zapisowy, ponieważ zapis zwykle angażuje dodatkowe operacje aplikacji, bazy danych i pamięci masowej.

Równolegle z wynikami użytkowymi zbiera się metryki infrastruktury. Na serwerze analizuje się użycie CPU, zajętość pamięci, aktywność i opóźnienia urządzeń dyskowych, liczbę operacji wejścia-wyjścia, ruch sieciowy oraz liczbę aktywnych połączeń. W systemach wieloprocesowych warto sprawdzić, czy obciążenie rozkłada się równomiernie na rdzenie, a w środowiskach z usługą HTTP również obserwować długość kolejek i liczbę aktywnych pracowników. Przydatne są logi dostępu z kodami odpowiedzi HTTP, logi aplikacyjne oraz identyfikatory korelacyjne pozwalające połączyć wolną odpowiedź z konkretnym etapem przetwarzania.

Interpretacja wyników i dalsza diagnostyka

Poprawny raport z load testingu powinien zawierać wersję badanego oprogramowania, konfigurację serwera, parametry generatora ruchu, dane wejściowe, czas trwania każdej fazy oraz opis scenariusza. Należy zapisać, czy test był wykonywany z pamięcią podręczną, czy bez niej, jak długo trwało rozgrzewanie aplikacji i czy dane testowe były stałe. Bez tych informacji trudno porównać dwa pomiary. Wynik należy oceniać względem wcześniej ustalonych progów, a nie tylko względem pojedynczego udanego uruchomienia.

Jeżeli opóźnienia rosną przy niewielkim wzroście liczby żądań, warto sprawdzić kolejki, blokady, pulę połączeń oraz operacje wejścia-wyjścia. Wysokie użycie CPU przy małej liczbie błędów może wskazywać na kosztowne obliczenia lub nieefektywne przetwarzanie żądań. Niska aktywność CPU połączona z dużymi opóźnieniami często kieruje diagnostykę ku oczekiwaniu na dysk, sieć albo usługę zależną. Po zmianie konfiguracji lub kodu test należy powtórzyć w porównywalnych warunkach, ponieważ pojedynczy pomiar nie rozstrzyga, czy poprawa jest trwała. Test obciążeniowy nie zastępuje testu odporności na nagły skok ruchu ani testu długotrwałego, które sprawdzają odpowiednio reakcję na gwałtowny wzrost oraz problemy ujawniające się po wielu godzinach pracy.