jeśli masz witrynę e-commerce (lub dowolną witrynę), nie jest rzadkością, że można oczekiwać wyższego poziomu ruchu w określone dni, takie jak na przykład Czarny piątek. W takich chwilach musimy przenieść nasze testy obciążenia na wyższy poziom i symulować większą liczbę jednoczesnych użytkowników. Jeśli uruchamiamy nasze testy obciążenia lokalnie za pomocą Apache JMeter™, istnieją pewne ograniczenia co do liczby użytkowników, które możesz uruchomić, nawet jeśli twój komputer ma wystarczająco dużo procesora i pamięci.
jak możemy stworzyć scenariusz z ponad 800 jednoczesnymi użytkownikami korzystającymi z JMeter? Jedną z odpowiedzi jest uruchomienie Jmetera w trybie rozproszonym. Dla tych z Was, którzy nigdy o tym nie słyszeli, oto krótkie wyjaśnienie.
kiedy mówimy o dystrybucji JMeter, odnosimy się do architektury Master-Slave, w której JMeter używa Java RMI do interakcji z obiektami w sieci rozproszonej. Widać to na poniższym obrazku.
Distributed testing umożliwia posiadanie lokalnego Jmetera (master), który obsługuje wykonanie testu, wraz z wieloma zdalnymi instancjami Jmetera (Slave), które wyśle żądanie do naszego serwera docelowego.
ale zanim będziesz w stanie uruchomić JMeter w sposób rozproszony, musisz wykonać kilka prostych kroków.
po pierwsze, musimy mieć wiele komputerów.
następnie musimy uruchomić serwer JMeter na każdym systemie slave, który mamy. W tym celu musimy uruchomić JMeter-server.bat (JMeter-serwer dla użytkowników Uniksa), który znajduje się w jmeter/bin. Po uruchomieniu powinniśmy zobaczyć coś takiego:
następnie, tą samą ścieżką, ale w systemie nadrzędnym, zlokalizuj jmeter.właściwości fil. Edytuj ten plik i dodaj adresy IP wszystkich systemów slave, które powinny być zaangażowane w właściwość remote_hosts. Upewnij się, że systemy master i slave znajdują się w tej samej podsieci.
bardzo ważne jest, aby pamiętać, że wszystkie wartości muszą być oddzielone przecinkami (w tym przykładzie używamy tylko jednego systemu slave, aby było to proste).
po wykonaniu wszystkich tych kroków możemy uruchomić JMeter i wykonać potrzebne testy. W tym przypadku uruchomimy JMeter za pomocą trybu GUI, więc możemy mieć lepsze wyobrażenie o tym, jak to działa. Jednak tryb inny niż GUI jest zdecydowanie zalecany do celów testowych.
liczba użytkowników, ramp up i iteracji powinna być skonfigurowana w grupie wątków systemów nadrzędnych jak zwykle. Podczas uruchamiania testu Warunki te będą replikowane na każdym systemie slave.
po uruchomieniu Jmetera i załadowaniu naszego testu mamy dwie opcje. Jeden, skonfigurowany przez system master, jest poprzez Run – >zdalny Start, a następnie wybierz system slave, w którym chcemy wykonać. Drugi, również skonfigurowany za pośrednictwem systemu nadrzędnego, jest uruchamiany – >Remote Start All, aby rozpocząć test na wszystkich dostępnych systemach podrzędnych.
(ponieważ ustawiliśmy tylko jeden system slave, nie ma różnicy między dwiema opcjami w tym przykładzie).
tutaj mamy prosty scenariusz, w którym możemy wyszukać i obejrzeć artykuł na stronie e-commerce:
jak widać, dodaliśmy podgląd drzewa wyników widoku, dzięki czemu możemy sprawdzić, czy test został wykonany poprawnie, czy nie. Kiedy uruchamiamy test zdalnie, będziemy mogli lokalnie zobaczyć wynik testu na drzewie wyników widoku, jak już wspomniałem, ale w systemach slave możemy obserwować tylko czas rozpoczęcia i czas zakończenia testu.
:
Zdalnie:
za kulisami każdy system slave wykonuje testy obciążenia w warunkach, które ustawiliśmy w systemie nadrzędnym. W ten sposób osiągamy większą liczbę jednoczesnych użytkowników, a tym samym większe obciążenie naszego serwera docelowego.
dlatego, jeśli chcemy naprawdę rozłożyć obciążenie, musimy to zrobić ręcznie. Na przykład: jeśli chcemy osiągnąć 10 000 jednoczesnych użytkowników i mamy 10 systemów slave, nasz plan testowy musi mieć 1000 użytkowników, więc w końcu mamy 10 000 łącznie.
kolejną ciekawą rzeczą, jaką możemy zrobić, jest dodanie logiki do naszego testu poprzez dodanie kontrolera If. Kontroler If pozwala nam wybrać konkretny przepływ, który chcemy wykonać, w zależności od systemu, który wykonuje test. Ao, różne systemy slave będą uruchamiać różne części testu.
na przykład, jeśli dodamy parametr podczas uruchamiania jmeter-serwera na systemach slave (./ JMeter-server-jparam=1) możemy umieścić warunek taki jak ${__javaScript(${param}==1)} w kontrolerze If, dzięki czemu możemy wykonywać określone żądania w zależności od systemu slave.
to jest to! Pomyślnie przeprowadziliśmy test na rozproszonym systemie JMeter. Może to nie wyglądać zbyt skomplikowanie, ponieważ zdecydowaliśmy się użyć tylko jednego systemu slave. Ale jeśli chcesz symulować 25 000 jednoczesnych użytkowników, koszt utrzymania wszystkich tych systemów jest ogromny. Możliwe jest obejście problemów z konserwacją, a mianowicie zamontowanie całej architektury, którą widzieliśmy w kontenerach Docker (przykład można zobaczyć tutaj).
jednak nadal nie będzie to wystarczająco dobre, jeśli naszym celem jest okresowe Uruchamianie testów obciążenia. Zainstalowaliśmy całą architekturę rozproszoną w jednym komputerze, więc zużywamy znaczną ilość zasobów. Koncepcja dystrybucji JMeter przez Dockera ma większy sens, jeśli mamy możliwość eskalacji liczby kontenerów na żądanie, jak w usłudze Cloud computing.
kolejną trudnością podczas uruchamiania Jmetera w trybie rozproszonym jest obsługa plików CSV po parametryzowaniu danych w testach. Dzieje się tak dlatego, że musimy mieć oddzielne pliki, a jeśli mamy je aktualizować, musimy przejść do każdego systemu slave i dokonać modyfikacji.
aby rozwiązać wszystkie te ograniczenia i niedogodności, możemy użyć BlazeMeter, który zapewnia nam łatwy sposób obsługi naszych testów obciążenia. Wszystko, co musimy zrobić, aby przesłać nasz plik JMX do BlazeMeter. Możemy również przesłać skonsolidowany plik CSV ze wszystkimi niezbędnymi danymi, a BlazeMeter zajmie się jego podziałem, w zależności od ilości ustawionych silników.
na BlazeMeter możemy ustawić ilość użytkowników lub kombinację silników (systemów slave) i wątków, które chcemy zastosować do naszych testów. Możemy również skonfigurować dodatkowe wartości, takie jak wiele lokalizacji.
wyniki badań:
to jest to! Teraz widziałeś kilka rozwiązań dla testów obciążeniowych na dużą skalę, moją rekomendacją jest stworzenie własnego doświadczenia i podjęcie decyzji, która opcja zapewnia większe korzyści.
dowiedz się więcej o tym, jak korzystać z JMeter z naszej bezpłatnej Akademii JMeter.
