Testowanie obciążenia. Porównanie narzędzi k6 i JMeter

Darmowym narzędziem typu open source, służącym do testowania obciążenia, w całości zbudowanym w Javie, jest JMeter. Pierwszy raz wydany w 1998 roku, z miejsca podbił serca użytkowników, oddając w ich ręce coś, za co do tej pory inne firmy kazały sobie słono płacić. Chociaż w JMeter skrypty można rozszerzać za pomocą kodu, większość z nich budowana jest za pomocą interfejsu użytkownika. Z kolei w 2017 roku LoadImpact wydał swoje narzędzie typu open source przeznaczone do testowania obciążenia – k6. Narzędzie stworzone jest w oparciu o Go, jednak skrypty bazują na JavaScript. Główną cechą k6 są skrypty wymagające kodowania co promuję doświadczonych programistów. 

Nie ma jednoznacznie "najlepszego" narzędzia; istnieje tylko właściwe narzędzie, dobrane odpowiednio do projektu i jego kontekstu. Postaramy się jednak udzielić odpowiedzi na pytanie w jakich sytuacjach sprawdza się każde z tych narzędzi?

Co wyróżnia JMeter?

1. GUI.
   
   Użycie Graficznego Interfejsu Użytkownika przyda się w sytuacjach, w których zespół nie ma doświadczenia w wykonywaniu testów obciążeniowych i musi nauczyć się od podstaw nowego narzędzia. To, które oparte jest na GUI, może okazać się najmniej problematycznym wyborem dla testerów, którzy są przyzwyczajeni do bezkodowych interfejsów użytkownika (takich jak Postman lub SoapUI).
2. Obsługa wielu protokołów i funkcji.
   
   Lista protokołów obsługiwanych przez JMeter jest długa. Ma on także większość funkcji potrzebnych do wykonania podstawowych testów obciążenia, co znaczy, że nie trzeba samemu go okodować. Struktura elementów nadrzędnych i podrzędnych oznacza, że pojawia się możliwość modyfikacji określonych elementów, takich jak modyfikacja wszystkich żądań http.
3. Doświadczona społeczność z mnóstwem dokumentacji.
   
   Początki JMetera sięgają 1998 roku. Jest on obecny na prawie każdym fachowym forum społecznościowym i bez względu na to, jak konkretny będzie przypadek użycia tego narzędzia , to są szanse, że ktoś już kiedyś zrobił to samo. JMeter może pochwalić się obszerną i bardzo dokładną dokumentacją swoich komponentów, w której każdy element, funkcja i jego właściwość są omówione niezwykle szczegółowo. Oprócz oficjalnej dokumentacji istnieją także setki książek, samouczków i kursów stworzonych przez jego pasjonatów. Dowodem na to jest repozytorium JMeter na GitHubie, które pod koniec 2020 roku miało już ponad 17000 zatwierdzeń. 
4. Tanie rozwiązanie do testowania obciążenia rozproszonego.
   
   JMeter sprawdzi się doskonale, gdy niezbędny jest tani sposób na testowanie obciążenia rozproszonego. Zapewnia on framework do uruchomienia takiego typu testów. Oznacza to zwiększenie generowanego obciążenia za pomocą zwiększenia liczby użytkowników wirtualnych i uruchomienie wielu równoległych skryptu w różnych generatorach obciążenia. W JMeter dzieje się to poprzez wyznaczenie węzła (controller node) i umożliwienie skonfigurowania tzw. węzłów roboczych (workers nodes), z których każdy posiada kopię jmeter-server, narzędzia dołączonego do każdej instalacji JMeter (w jmeter/bin).
   
   
   *) źródło: Apache JMeter
   
   Węzły robocze w kolejnym kroku uruchamiają kopie planu testów i obciążają serwer aplikacji. Jako węzły robocze można użyć maszyny lokalne, można wykorzystać do tego również chmurę. Takie rozproszone wykonanie zajmuje co prawda trochę czasu, ale działa satysfakcjonująco dobrze.
   
   k6 z kolei obsługuje tryb testowania obciążenia rozproszonego za pośrednictwem Kubernetes, który umożliwia utworzenie niestandardowego obiektu zasobu k6 w klastrze Kubernetes. 
   
   W porównaniu do k6 JMeter okazuje się dość zasobożerny i dlatego jest bardziej prawdopodobne, że będzie wymagał więcej generatorów obciążenia. W zależności od zasobów pojedynczego generatora JMeter może obsługiwać średnio około tysiąca użytkowników wirtualnych, a skalowanie testu poza ten punkt będzie wymagało konfiguracji uruchomienia rozproszonego. 
5. Gotowe raporty wbudowane w narzędziu do testowania obciążenia.
   
   JMeter pozwala decydować, w jakim formacie powinny być wyświetlane wyniki. Debugowanie? Można użyć drzewa wyników. Potrzebne są metryki do testu obciążenia? Do wyboru jest także raport podsumowujący lub zbiorczy. 
   
   
   Ponadto JMeter pozwala generować raporty w HTML tworzone na podstawie wyników uruchomienia testów obciążenia. Są one dość ograniczone, ale też dość funkcjonalne. Mają też kilka domyślnych wykresów, które ułatwiają przeanalizowanie wyników testów obciążenia. Nie są interaktywne, ale łatwe do wygenerowania i stanowią dobry punkt wyjścia do stworzenia szablonu raportu z testów
   
   
   W przeciwieństwie do JMeter k6 nie może pochwalić się wbudowanym raportowaniem. Można za to zintegrować go z wieloma innymi narzędziami do analizy danych, np. Grafana, Datadog, New Relic, Amazon CloudWatch i k6 Cloud, które ostatecznie są lepszymi narzędziami analitycznymi i mogą dostarczyć więcej informacji niż te, które dają raporty generowane przez JMeter, ale wymagają skonfigurowania innego narzędzia do analizy testów, a to jak wiadomo, wymaga dodatkowego nakładu czasu i pracy. 

Co wyróżnia k6?

1. Szybki start.
   
   Samo rozpoczęcie pracy z obydwoma narzędziami jest szybkie i proste, ale dzieje się tak z różnych powodów. Proces instalacji k6 jest szybki, co więcej nie wymaga on nodeJS ani żadnych innych komponentów. JMeter też instaluje się łatwo, jednak zanim przejdziemy do jego zainstalowania, musimy mieć zainstalowaną Javę. Tu mogą pojawić się problemy z dodawaniem zmiennych środowiskowych potrzebnych do jej działania, czasami trudno też określić, która wersja Javy jest właściwa. 
   
   k6 obsługuje wtyczki, ale nie są one potrzebne. W większości przypadków wbudowana funkcjonalność narzędzia powinna w zupełności wystarczyć (oprócz wspomnianych wcześniej raportów). Kontrastuje to z JMeter, gdzie wszystko jest wtyczką, łącznie z samym menedżerem wtyczek. Określa się, że istnieje standardowy zestaw wtyczek, które należy pobrać, zanim rozpocznie się korzystanie z narzędzia, a to może wprowadzać zamieszanie, zwłaszcza wśród nowych użytkowników narzędzia. 
   
   Skrypty k6 stworzone są w JavaScript, co znacznie ułatwia ich pisanie i uruchamianie. Wszystko czego użytkownik potrzebuje, to jeden instalator lub pojedyncze polecenie na terminalu oraz dowolny edytor tekstu. W przypadku JMeter, przed rozpoczęciem konieczne jest zainstalowanie kilku rzeczy lokalnie: Java, samego JMeter-a i standardowy zestaw wtyczek, których użytkownik będzie potrzebować do pracy z narzędziem.
2. Maksymalizacja wydajność i efektywność.
   
   Kiedy mowa jest o symulacji wielu wirtualnych użytkowników, musimy przekalkulować niską wydajnością narzędzia, która równa jest wysokim kosztom uruchomienia testów. Liczba używanych generatorów obciążenia będzie wiązać się z kosztem, niezależnie od tego, czy jest to koszt ich nabycia i utrzymania (lokalnie), czy koszt usługi w chmurze. Z tego też względu sensowne będzie rozważenie ograniczeń wydajności narzędzia do testowania obciążenia przed użyciem go do kontroli wydajności własnej aplikacji.
   
   k6 napisany jest w Go, który zbudowany jest właśnie z myślą o wydajności. To język kompilowany, który nie wymaga interpretacji, jak to się dzieje w przypadku Javy czy Pythona, nie jest on szczególnie złożony, ani nie posiada zewnętrznych zależności. Im mniej ruchomych części w całym mechanizmie, tym mniej potencjalnych źródeł wąskiego gardła. Najprostszym i najczęstszym sposobem, w jaki narzędzie do testowania obciążenia może uruchomić użytkownika wirtualnego, jest przypisanie jednego użytkownika wirtualnego do jednego jądra lub wątku systemu operacyjnego. Jednak w paradygmacie 1 wątek = 1 użytkownik wirtualny pojawia się poważna wada: kiedy wirtualny użytkownik czeka na odpowiedź lub wykonuje zaprogramowaną funkcję sleep(), wątek jest blokowany i nie może w nim przetwarzać innych zadań. 
   
   W k6 każdy wirtualny użytkownik jest uruchamiany na tzw. goroutine, a nie na wątku. Goroutine sterowane są za pomocą czegoś, co nazywa się Go Scheduler, działający jak policjant sterujący ruchem; potrafi on ponownie wykorzystać nieaktywne wątki i inteligentnie przypisuje prace, umożliwiając przekazywanie jej między wątkami. Jest to ta sama zasada, na której opierają się load balancery: zewnętrzny monitor nadzorujący przepływ pracy poprawia ogólną wydajność. Możliwość wykorzystania wbudowanych optymalizacji wydajności języka Go przekłada się na mniejsze wykorzystanie pamięci, dzięki temu jeden wątek z k6 nie przekracza 100 kb, podczas gdy wątek JVM, taki jak JMeter, używa domyślnego 1 MB. Co prawda Java pozwala użytkownikowi dostosować wykorzystanie pamięci przez aplikację, dlatego też różnica zazwyczaj nie będzie aż tak wyraźna, ale nadal warto zauważyć, że Go ma znacznie niższy punkt wyjścia.
3. Gwarancja większej wydajności
   
   Lepsza wydajność k6 oznacza, że do wygenerowania określonej wielkości obciążenia potrzeba mniej generatorów. Dodatkowo k6 ma niższe zużycie pamięci, dzięki czemu może on obsługiwać więcej wirtualnych użytkowników i generować większe niż przeciętnie obciążenie. Niezależnie od tego, czy używane są lokalne generatory obciążenia, czy w chmurze, finalny koszt aprowizacji będzie z pewnością mniejszy. Jest to oszczędność, która może zadecydować o wyborze k6 przez zespoły dbające o swój budżet.
   
   k6 różni się też od wielu innych narzędzi do testowania obciążenia tym, w jaki sposób obsługuje zasoby sprzętowe. Pojedynczy proces k6 efektywnie wykorzystuje wszystkie rdzenie procesora na maszynie generującej obciążenie. Pojedyncza instancja k6 często wystarcza do wygenerowania obciążenia 30 000-40 000 jednoczesnych użytkowników (VU), co w efekcie generuje do 300 000 żądań na sekundę (RPS).
   
   Kolejnym elementem pozytywnie wpływającym na wydajność k6 jest brak GUI, które zazwyczaj znacznie obciążają aplikację. Kiedy przeprowadzany jest test obciążenia, najbardziej wskazane jest uruchomienie go z wiersza poleceń. Narzędzia do testowania obciążenia oparte na kodzie działają od samego początku. Wyeliminowanie GUI oznacza wyeliminowanie jednego z problemów. 
4. Przeprowadzanie testów zorientowanych na cel.
   
   Rozpoczynając nowy projekt testowania obciążenia należy zadać sobie istotne pytanie: „dlaczego”? Plany testów powinny być tworzone w odpowiedzi na powody, dla których zespół chce przeprowadzić testy obciążeniowe, co powinno znaleźć odzwierciedlenie w wymaganiach niefunkcjonalnych. Z kolei wymagania niefunkcjonalne powinny dawać pewne wskazówki dotyczące granic wydajności. JMeter standardowo nie obsługuje progów na poziomie testu. Można to oczywiście obejść na kilka sposobów, jednak nadal są to tylko obejścia, które nie są dostarczane razem z JMeter lub nie odnoszą się odpowiednio do tworzenia różnych typów progów (błąd, czas odpowiedzi, przepustowość, procesor, pamięć). Najczęściej stosowanym przez użytkowników rozwiązaniem jest eksportowanie surowych danych z JMeter i samodzielne przeprowadzanie analizy za pomocą innego narzędzia.
5. Wykorzystywanie w zespole, w którym skrypty może pisać więcej niż jedna osoba.
   
   k6 sprawdzi się jako narzędzie, z którym oprócz testerów mogą pracować także programiści. Wypełnia ono lukę, wprowadzając koncepcję i funkcje testerskie do środowiska i językiem, z którym programiści już się zetknęli. JavaScript jest łatwym podejściem do pisania skryptów testów obciążenia, a k6 działa dobrze z dowolnym IDE lub edytorem tekstu. 
6. Łatwość w utrzymaniu
   
   Jedynym zmartwieniem dotyczącym k6 to jego wersje oraz wersja skryptów. Żadne inne zależności nie są wymagane. Niezbędne będzie jedynie śledzenie wtyczek, jeśli oczywiście są one wykorzystywane do pracy z narzędziem. To zupełne przeciwieństwo JMeter, przy pracy z którym należy pamiętać o aktualizacji wielu elementów, takich jak wersja samego JMetera, Javy, wersje wtyczek, a także samego skryptu. Kolejnym ułatwieniem jest łączenie kodu testowego z kodem aplikacji. Jeśli kod aplikacji napisany jest w JavaScript, k6 będzie właściwym narzędziem do testowania obciążenia. Pozwala to tworzyć testy, które są ściśle zintegrowane z kodem aplikacji, importując obiekty i bezpośrednio z nimi współpracując. Takie podejście ograniczy dużo czasu spędzanego na refaktoryzacji skryptów testowych, gdy obiekty są zmieniane.

Podsumowanie

Jedno i drugie narzędzie radzi sobie dobrze w generowaniu obciążenia. Niestety ani JMeter, ani k6 nie obsługują szczegółowej analizy wyników. 

JMeter jest więc najlepszy dla:

• tradycyjnych zespołów testowych,
• użytkowników, którzy szukają narzędzia do testowania opartego na GUI z mnóstwem samouczków i szeroką obsługą protokołów,
• dotychczasowych użytkowników narzędzi komercyjnych, takich jak LoadRunner i NeoLoad.

k6 jest z kolei najlepszy dla:

• współpracujących ze sobą zespołów inżynierskich, w których testowanie obejmuje wiele ról,
• użytkowników, którzy szukają prostego i lekkiego, a jednocześnie w pełni funkcjonalnego narzędzia do testowania obciążenia,
• zespołów, które chcą zintegrować testowanie z istniejącymi przepływami pracy deweloperskiej i strumieniami CI/CD.

Szkolenie

Chcesz dowiedzieć się więcej o korzystaniu z k6 w praktyce? Weź udział w naszym szkoleniu Testy wydajnościowe w k6.

Najbliższy termin szkolenia 6-8 lutego 2023 w formie online. Zapisz się na szkolenie tutaj.