Test obciążeniowy to kontrolowana próba wytrzymałości.
Kontrolowana, bo środowisko, scenariusz i moment wybierasz ty. Nie narzuca ich ruch, który akurat przyszedł. Ruch zwiększamy, aż system padnie. To awaria na twoich warunkach i dopiero ona pokazuje, gdzie leży prawdziwa granica.
W tym przewodniku
Jak przebiega próba
Od celu i scenariusza, przez narastanie i utrzymanie szczytu, po kontrolowane spotkanie z granicą.
Czego wymaga po twojej stronie
Środowisko, dane testowe, dostępy, okno czasowe i ktoś, kto odbierze telefon w trakcie. Przy każdym braku jest plan B.
Co dostajesz na końcu
Diagnozę z priorytetami i ten sam test po każdej poprawce, aż system osiągnie cel.
Na czym to polega
Symulujemy ruch, zwiększamy obciążenie, patrzymy na liczby.
„Zobaczymy, jak zachowa się na produkcji” to też test obciążeniowy, tylko bez scenariusza, bez pomiaru i bez przycisku stop. Płacą za niego klienci, którzy akurat trafili na awarię, a wyniku i tak nie ma, bo nikt nie mierzył. W kontrolowanej próbie ruch jest ten sam, ale jego wielkość i moment ustalasz ty.
Symulujemy ruch
Wirtualni użytkownicy przechodzą przez system tą samą ścieżką co prawdziwi: logują się, szukają, dodają do koszyka, płacą. Do systemu docierają takie same żądania jak od prawdziwych użytkowników.
Zwiększamy obciążenie
Ruch rośnie według profilu ustalonego w scenariuszu: stopniowo, falami albo skokiem, tak jak wygląda twój prawdziwy szczyt.
Patrzymy na liczby
Przez cały czas mierzymy, jak system odpowiada: czasy, błędy, zużycie zasobów. Czasy odpowiedzi rosną i zasoby się wyczerpują wcześniej, niż pojawi się pierwszy błąd widoczny dla użytkownika.
Rodzaje testów
Rodzaj testu to kształt ruchu.
Pod spodem to zawsze ta sama mechanika. Różni się kształt ruchu, który puszczamy, a każdy kształt odpowiada na inne pytanie o twój system. Potocznie „load test” bywa nazwą dla całości; tu oznacza pierwszy z tych kształtów.
Test docelowego ruchu(load test)
Czy udźwigniemy to, co planujemy?
Ruch rośnie stopniowo do poziomu, który zakładasz na kampanię, premierę albo szczyt sezonu, i trzyma się go na tyle długo, żeby wynik nie był przypadkiem. Odpowiedź brzmi „tak” albo „nie”. A jeśli „nie”, wiesz dokładnie, ile brakuje.
Szukanie granicy(stress test)
Gdzie dokładnie system się kończy?
Zwiększamy ruch ponad plan, aż pojawią się pierwsze błędy. Wynik to dwie konkretne rzeczy: przy jakim natężeniu system przestaje odpowiadać poprawnie i który element ustąpił pierwszy.
Nagły skok(spike test)
Co się stanie, gdy tłum wejdzie naraz?
Zamiast łagodnego narastania ruch skacze do szczytu w kilkanaście sekund, jak po wysyłce newslettera albo emisji reklamy. Mierzymy, ile żądań system obsłuży, ile odrzuci i jak szybko czasy odpowiedzi wracają do normy.
Długa próba(soak test)
Czy wytrzyma cały dzień, nie tylko kwadrans?
Umiarkowany ruch utrzymywany godzinami. Wyciek pamięci, pęczniejące kolejki, kończące się połączenia do bazy. Te awarie nie biorą się z jednego szczytu, tylko z godzin pracy. Krótki test ich nie pokaże.
Co mierzymy
Tempo, czasy odpowiedzi, błędy, zużycie zasobów.
Żądania na sekundę
Ile pracy system przyjmuje w każdej sekundzie. W trakcie przebiegu zwiększamy natężenie ruchu i patrzymy, jak długo ta liczba nadąża. Moment, w którym przestaje rosnąć, choć ruchu przybywa, to pierwszy sygnał granicy.
Czas odpowiedzi w percentylach
Średnia ukrywa najwolniejsze odpowiedzi, dlatego patrzymy na percentyle. p95 mówi, że 95 na 100 żądań zmieściło się w tym czasie, a 5 czekało dłużej. p99 to najwolniejsze 1 na 100. Jedna odsłona strony to kilkadziesiąt żądań, więc na to najwolniejsze 1 na 100 trafia mniej więcej co trzeci użytkownik.
Błędy
Odsetek żądań, które nie dostały odpowiedzi albo dostały złą. Długo trzyma się przy zerze i rośnie skokowo tuż przy granicy. Dlatego to jeden z najwyraźniejszych sygnałów, że właśnie ją znaleźliśmy.
Zużycie zasobów
Procesor, pamięć, pula połączeń do bazy danych. Coś zawsze wyczerpuje się pierwsze. Test pokazuje co. To zwykle pierwsza pozycja na liście poprawek.
Liczby w tej sekcji są pokazowe. Ilustrują mechanizm działania; nie pochodzą z żadnego konkretnego testu.
Krok po kroku
Ruch nie bierze się znikąd.
Sam przebieg, czyli moment, w którym płynie ruch, to tylko środek procesu. Przed nim jest przygotowanie, a po nim analiza wyników, czyli najważniejsza część.
Zanim popłynie ruch
01
Cel testu
Zaczynamy od liczby. Ile ruchu system ma wytrzymać? Szczyt z zeszłego sezonu razy dwa? Ruch z kampanii, którą planujesz? Ta liczba staje się celem testu. Bez niej wynik nie ma punktu odniesienia i nie wiadomo, kiedy skończyć.
02
Wiedza o systemie
Zbieramy to, z czego powstanie scenariusz: dokumentację API, opis ścieżek użytkownika, nagranie ruchu. Nie musisz mieć wszystkiego. Z tego, co jest, składamy obraz systemu i uzupełniamy go rozmową z kimś, kto system zna.
03
Realistyczne scenariusze
Prawdziwi użytkownicy nie odświeżają jednej strony. Logują się, szukają, wracają, porzucają koszyki. Scenariusz odwzorowuje te zachowania i ich proporcje, bo system, który obsłuży tysiące odsłon strony głównej, może nie wytrzymać kilkudziesięciu równoczesnych zapisów do bazy.
04
Dane testowe
Konta, produkty, zamówienia w takiej skali jak naprawdę. Na pustej bazie zapytania wykonują się szybciej niż na produkcyjnej, więc wynik wychodzi zawyżony. Przygotowanie danych bierzemy na siebie; od ciebie potrzebujemy wiedzy, jak wyglądają prawdziwe.
Sam przebieg
Faza 01
Narastanie
Najpierw kilka minut na małym ruchu. Sprawdzamy, czy scenariusz przechodzi, dane działają, a logi po twojej stronie widzą nasze żądania; przy okazji rozgrzewa się cache, więc pomiar nie łapie efektu zimnego startu. Potem ruch rośnie stopniowo, według profilu ze scenariusza. Na tym zboczu widać najwięcej: przy jakim natężeniu czasy odpowiedzi zaczynają rosnąć, co dzieje się z bazą i który zasób wyczerpuje się pierwszy.
Faza 02
Utrzymanie
Docelowy poziom trzymamy na tyle długo, żeby wykluczyć przypadek. System, który wytrzymuje szczyt przez chwilę, to co innego niż system, który trzyma go stabilnie. Dopiero ta faza to rozstrzyga.
Faza 03
Granica
Jeśli celem jest znalezienie granicy, idziemy wyżej, ponad plan, do pierwszych błędów. To kontrolowana awaria. Wiadomo, kiedy nastąpiła, przy jakim ruchu i co ustąpiło pierwsze. Ta sama granica znaleziona na produkcji oznacza niedostępność dla klientów.
Przez cały przebieg patrzymy na metryki na żywo, te same liczby, które znasz już z tej strony. Gdyby działo się coś niepokojącego, test można zatrzymać jednym kliknięciem.
Po przebiegu: pętla
01
Analiza wyników
Zestawiamy nasz pomiar z metrykami po twojej stronie, czyli co było widać z zewnątrz i co w tym samym momencie działo się w środku. Z tego zestawienia widać, co się zepsuło i dlaczego.
02
Diagnoza z priorytetami
Dostajesz listę wąskich gardeł uporządkowaną od najbardziej dotkliwego. Przy każdym: co zmierzyliśmy, co to powoduje i od czego zacząć poprawkę.
03
Poprawka i powtórka
Poprawkę wprowadza twój zespół, bo to twój kod i twoja infrastruktura. Potem puszczamy dokładnie ten sam test jeszcze raz i porównujemy wynik przed i po. Pętla kręci się, aż system osiągnie cel ustalony na początku. Tak wygląda ta pętla.
Co stoi za tym ruchem
Po naszej stronie
Ruch powstaje na skalowalnych maszynach w chmurze, nie na jednym laptopie. Wychodzi z wielu adresów naraz, jak prawdziwy tłum, a jego natężenie zmieniamy w trakcie, co do sekundy i co do zadanego tempa. Maszyny stawiamy tam, gdzie wymaga tego cel: blisko twojego systemu, gdy mierzymy sam system, albo dalej, gdy chcemy zobaczyć także narzut sieci. Te same maszyny zapisują każdą odpowiedź systemu: czas, kod, treść błędu. Po przebiegu składamy z tego raport.
Po twojej stronie
Środowisko o parametrach możliwie bliskich produkcji (co to znaczy dokładnie, mówi lista niżej). Do tego logi i metryki aplikacji oraz bazy, żeby dało się zajrzeć do środka, gdy z zewnątrz widać już tylko objaw. I przepustowość sieci, która nie zdusi testu, zanim dotrze do systemu.
Jak to się łączy
Te dwa światy spina jedno uzgodnione połączenie: nasze adresy na twojej liście dozwolonych, wskazany adres środowiska i okno czasowe. Ruch przychodzi z zewnątrz, tą samą drogą co ruch klientów.
Cały przebieg jest opisany w scenariuszu, który czytasz przed startem. Tak wygląda scenariusz.
Po twojej stronie
Co przygotować, żeby wynik był wiarygodny.
Test obciążeniowy to współpraca. Środowisko, dane, dostępy i czyjaś uwaga w trakcie. To one dzielą wiarygodny wynik od zgadywania. Przy każdym punkcie piszemy, co zrobić, jeśli akurat tego nie masz.
- 01
Środowisko
Miejsce, w które popłynie ruch: osobne środowisko testowe albo staging o parametrach możliwie bliskich produkcji, czyli ta sama baza, te same limity, podobna moc. Im bliżej produkcji, tym mniej wynik trzeba „przeliczać w głowie”. Środowisko o połowie mocy nie odpowie wprost na pytanie o produkcję.
A jeśli tego nie masz
Masz tylko produkcję? Da się. Test w oknie nocnym, z ostrożniejszym profilem i planem natychmiastowego stopu. Kompromis polega na tym, że mniej swobodnie szukamy granicy, za to środowisko jest w pełni wiarygodne. Omawiamy go otwarcie przed startem.
- 02
Dane testowe
Konta, na które można się logować, produkty, które można kupować, historia zamówień w realistycznej skali. Zapytanie bez indeksu na kilkuset rekordach wykonuje się w milisekundach; na milionie tych samych rekordów potrafi trwać sekundy. Test na pustej bazie tej różnicy nie pokaże.
A jeśli tego nie masz
Wygenerujemy dane razem z tobą. Potrzebujemy tylko wiedzy, jak wyglądają prawdziwe, czyli ile czego i w jakich proporcjach. Co zrobić z danymi po teście, usunąć czy zostawić, ustalamy przed startem.
- 03
Opis systemu
Dokumentacja API, specyfikacja, nagranie ruchu: cokolwiek, co pokazuje, którędy chodzą użytkownicy i jak rozmawiają z systemem. Z tego powstaje scenariusz, który potem czytasz i zatwierdzasz. Im lepszy materiał, tym mniej domysłów w scenariuszu.
A jeśli tego nie masz
Braki nadrabiamy rozmową z kimś, kto zna system, i nagraniem prawdziwej sesji. Brak dokumentacji spowalnia, ale nie zatrzymuje.
- 04
Okno czasowe
Uzgodniony termin przebiegu: taki, w którym ruch testowy nikomu nie przeszkadza i nikt nie wdraża zmian w trakcie. Wdrożenie w środku testu unieważnia wynik, bo nie wiadomo, co mierzyliśmy, system przed zmianą czy po niej.
A jeśli tego nie masz
Kalendarz napięty? Okno dobieramy do twojego rytmu, także poza godzinami pracy.
- 05
Monitoring po twojej stronie
Dostęp do metryk i logów aplikacji oraz bazy w czasie testu albo człowiek, który patrzy w nie po twojej stronie. Nasz pomiar pokazuje, jak system odpowiada z zewnątrz. Twoje metryki pokazują dlaczego. Dopiero razem dają przyczynę, nie tylko objaw.
A jeśli tego nie masz
Podpowiemy, co włączyć. Większość hostingów udostępnia podstawowe metryki w panelu, wystarczy je otworzyć.
- 06
Zgody i bezpieczeństwo
Potwierdzenie, że system jest twój albo masz zgodę jego właściciela; wpis naszych adresów na listę dozwolonych; uprzedzenie dostawcy hostingu lub CDN, gdy jego regulamin tego wymaga. Nieuprzedzony dostawca może zakwalifikować test jako atak i odciąć ruch w połowie przebiegu, co unieważnia wynik.
A jeśli tego nie masz
Nie wiesz, co na to twój hosting? Sprawdzimy razem warunki i limity, zanim cokolwiek ruszy.
- 07
Człowiek do kontaktu
Jedna osoba po twojej stronie, która zna system albo wie, kto go zna, i jest uchwytna w oknie testu. Pytania pojawiają się w konkretnych momentach, przy budowie scenariusza i w trakcie przebiegu. Szybka odpowiedź trzyma tempo.
A jeśli tego nie masz
Nie musi to być programista. Wystarczy ktoś, kto sprawnie łączy nas z właściwymi ludźmi.
- 08
Gotowość do poprawek
Zespół, twój albo wskazany przez ciebie, który może wprowadzać zmiany po diagnozie. Test ma największy sens, gdy ktoś domyka pętlę: test, poprawka, ten sam test jeszcze raz. Bez poprawek zostaje sama lista znanych problemów, a granica systemu pozostaje tam, gdzie była.
A jeśli tego nie masz
Diagnoza mówi precyzyjnie, co i gdzie, a przy wdrażaniu możemy usiąść z twoim zespołem i pokazać, co poprawić.
- 09
Integracje zewnętrzne
Płatności, wysyłka e-maili i SMS-ów, API partnerów. Przy dużym ruchu te połączenia trzeba zaślepić: podstawiamy zaślepki, które odpowiadają jak prawdziwy dostawca, tylko nic nie wysyłają i nie kosztują. Środowiska testowe dostawców (sandbox) nie udźwigną takiego ruchu, a produkcyjne nie powinny go zobaczyć.
A jeśli tego nie masz
Nie wiesz, gdzie system wychodzi na zewnątrz? Listę integracji składamy z opisu systemu i z nagrania ruchu, a zaślepki przygotowujemy razem ze scenariuszem.
Połowa tej listy zwykle powstaje dopiero na pierwszym spotkaniu. Braki to normalny punkt wyjścia, nie przeszkoda. Porozmawiajmy.
Pytania i wątpliwości
To, o co pyta każdy, kto słyszy o tym pierwszy raz.
Czym różni się test obciążeniowy od testu wydajności?
Granice są umowne, ale zwykle test wydajności pyta „jak szybko?”, a obciążeniowy „ile naraz?”. Pierwszy mierzy czas pojedynczej operacji, drugi sprawdza, co dzieje się z tym czasem, gdy operacje przychodzą tłumnie. Jedno bez drugiego niewiele mówi, dlatego w teście obciążeniowym i tak patrzymy na oba wymiary.
Czy test może coś zepsuć?
Może. Właśnie dlatego robi się go pod kontrolą: na uzgodnionym środowisku, w uzgodnionym oknie, ze scenariuszem, który czytasz przed startem, i z możliwością zatrzymania w każdej chwili. Awaria środowiska testowego to zresztą cenny wynik, bo pokazuje granicę, zanim znajdzie ją produkcja.
Ilu wirtualnych użytkowników potrzeba?
Tylu, ilu wymaga twój cel. Punktem wyjścia jest ruch, który system ma wytrzymać: szczyt z historii, plan kampanii, prognoza sezonu. Do tego zapas na szukanie granicy. Sama liczba użytkowników mało mówi; liczymy ją z docelowego natężenia ruchu i tempa, w jakim prawdziwi ludzie klikają. Ta liczba wynika z rozmowy o celu.
Czy test na środowisku testowym mówi coś o produkcji?
Tak, pod warunkiem że środowisko jest do produkcji podobne. Wtedy wynik przenosi się wprost. Im większa różnica, tym więcej trzeba interpretacji, dlatego różnice spisujemy przed testem i uwzględniamy w diagnozie, zamiast udawać, że ich nie ma.
Czy dane naszych klientów są bezpieczne?
Test pracuje na danych testowych, nie na danych klientów, czyli na kontach i rekordach przygotowanych specjalnie pod próbę. Ruch idzie na wskazane przez ciebie środowisko, a system i jego dane zostają u ciebie. My widzimy odpowiedzi systemu i metryki. Do zawartości twojej bazy nie mamy wglądu.
Co jeśli wynik będzie zły?
Po to jest test. „Zły wynik” to znaleziona granica plus lista przyczyn z priorytetami. Po twojej poprawce ten sam test rusza jeszcze raz i pokazuje, o ile granica się przesunęła. Ta sama informacja z produkcji przychodzi w trakcie awarii, przy klientach.
Reszta pytań zwykle dotyczy już konkretnego systemu. Na te odpowiadamy w rozmowie.
Wiesz już, jak to działa. Zostało pytanie o twój system.
Na „czym jest test obciążeniowy” odpowiada ta strona. Na „ile wytrzyma nasz system” odpowiedź zależy od twojego ruchu, kalendarza i celu, dlatego ustalamy ją w rozmowie.
30 minut · online · bezpłatnie