Przeprowadzasz test warunków skrajnych w aplikacji internetowej?

W przeszłości korzystałem z Microsoft Stress Tool i Pylot do testowania aplikacji internetowych. Napisałem prostą stronę główną, skrypt logowania i przewodnik po witrynie (w witrynie e-commerce dodając kilka elementów do koszyka i kasy).

Samo trafienie na stronę główną z garstką programistów prawie zawsze zlokalizowałoby poważny problem. Więcej problemów ze skalowalnością pojawi się na drugim etapie, a nawet więcej - po uruchomieniu.

Adres URL narzędzi, z których korzystałem, to Microsoft Homer (znany również jako narzędzie Microsoft Web Application Stress Tool ) i Pylot .

Raporty generowane przez te narzędzia nigdy nie miały dla mnie większego sensu, a ja spędziłem wiele godzin próbując dowiedzieć się, jaki rodzaj jednoczesnego obciążenia może obsłużyć witryna. Zawsze było warto, bo zawsze pojawiały się najgłupsze błędy i wąskie gardła (na przykład błędne konfiguracje serwera WWW).

Co zrobiłeś, jakich narzędzi użyłeś i jaki sukces odniosłeś dzięki swojemu podejściu? Najbardziej interesująca dla mnie część to wymyślenie pewnej sensownej formuły do ​​obliczania liczby równoczesnych użytkowników, których aplikacja może obsłużyć na podstawie liczb zgłoszonych przez aplikację do testów warunków skrajnych.

Oto kolejny głos na JMeter .

JMeter to narzędzie do testowania obciążenia typu open source, napisane w Javie. Jest w stanie przetestować wiele różnych typów serwerów (na przykład sieć, usługi sieciowe, baza danych, prawie wszystko, co zasadniczo korzysta z żądań).

Ma jednak stromą krzywą uczenia się, gdy zaczynasz przechodzić do skomplikowanych testów, ale warto. Możesz bardzo szybko rozpocząć pracę i może to być w porządku w zależności od rodzaju testów warunków skrajnych.

Plusy:

• Narzędzie Open-Source / Free z projektu Apache (pomaga przy zakupie)
• Łatwy do rozpoczęcia i łatwy w użyciu po zrozumieniu podstawowych koncepcji. (Tj. Jak utworzyć żądanie, jak utworzyć asercję, jak pracować ze zmiennymi itp.).
• Bardzo skalowalny. Przeprowadziłem testy z 11 maszynami generującymi obciążenie serwera w tempie prawie miliona odsłon na godzinę. Konfiguracja była znacznie łatwiejsza, niż się spodziewałem.
• Ma aktywną społeczność i dobre zasoby, które pomogą Ci rozpocząć pracę. Najpierw przeczytaj samouczki i baw się przez chwilę.

Cons:

• Interfejs użytkownika jest napisany w języku Swing. (ugh!)
• JMeter działa poprzez analizowanie tekstu odpowiedzi zwróconego przez serwer. Jeśli więc chcesz zweryfikować jakiekolwiek zachowanie javascript, nie masz szczęścia.
• Krzywa uczenia się jest stroma dla nie-programistów. Jeśli znasz wyrażenia regularne, już wyprzedzasz grę.
• Na forum wsparcia jest wielu idiotów ( wstawiających przekleństwa ), zadających głupie pytania, które można by łatwo rozwiązać, gdyby nawet przelotnie rzuciły okiem na dokumentację. („Jak używać JMeter do testowania warunków skrajnych mojego graficznego interfejsu użytkownika systemu Windows” pojawia się dość często).
• Raportowanie „po wyjęciu z pudełka” pozostawia wiele do życzenia, szczególnie w przypadku większych testów. W teście, o którym wspomniałem powyżej, musiałem napisać szybką aplikację konsolową, aby wykonać niektóre konwersje plików „xml-logfile” do „html”. To było kilka lat temu, więc jest prawdopodobne, że nie będzie to już wymagane.

Użyłem Grinder . Jest open source, dość łatwy w użyciu i bardzo konfigurowalny. Jest oparty na Javie i używa Jython do skryptów. Uruchomiliśmy go z aplikacją sieciową .NET, więc nie myśl, że jest to narzędzie wyłącznie Java (z natury rzeczy żadne narzędzie stresu sieciowego nie powinno być powiązane z używaną platformą).

Zrobiliśmy z nim kilka fajnych rzeczy ... byliśmy internetową aplikacją telekomunikacyjną, więc jednym z fajnych zastosowań, które skonfigurowałem, było naśladowanie wybierania numeru za pośrednictwem naszej aplikacji internetowej, a następnie skorzystaliśmy z narzędzia automatycznej odpowiedzi, które mieliśmy (co było w zasadzie samouczkiem aplikacja firmy Microsoft, aby połączyć się z serwerem RTC LCS ... z którym łączy się Microsoft Office Communicator w sieci lokalnej ... a następnie zmodyfikować tak, aby automatycznie odbierał połączenia). To pozwoliło nam użyć tego zamiast kosztownego narzędzia telefonicznego o nazwie The Hammer (lub coś w tym rodzaju).

W każdym razie użyliśmy tego narzędzia, aby zobaczyć, jak nasza aplikacja działa przy dużym obciążeniu, i było bardzo skuteczne w znajdowaniu wąskich gardeł. Narzędzie ma wbudowane funkcje raportowania, które pokazują, ile czasu zajmują żądania, ale nigdy go nie używaliśmy. Dzienniki mogą również przechowywać wszystkie odpowiedzi i inne lub rejestrowanie niestandardowe.

Bardzo polecam to narzędzie, bardzo przydatne w cenie ... ale spodziewam się, że zrobię z nim niestandardową konfigurację (ma wbudowane proxy do nagrywania skryptu, ale może wymagać dostosowania do przechwytywania czegoś takiego jak sesje ... Wiem Musiałem go dostosować, aby wykorzystywał unikalną sesję dla każdego wątku).

Trochę późno na to przyjęcie. Zgadzam się, że Pylot jest najlepszym dostępnym narzędziem typu open source. Jest prosty w obsłudze i aktywnie pracuje nad nim świetny facet ( Corey Goldberg ). Jako założyciel OpenQA cieszę się również, że Pylot jest teraz wymieniony na naszej stronie głównej i korzysta z naszej infrastruktury (a mianowicie z forów).

Ostatnio jednak zdecydowałem, że cała koncepcja testowania obciążenia jest wadliwa: emulowanie ruchu HTTP, przy tak złożonych aplikacjach, jak to jest kłopotliwe. Właśnie dlatego stworzyłem komercyjne narzędzie BrowserMob. Jest to zewnętrzna usługa testowania obciążenia, która wykorzystuje Selenium do sterowania prawdziwymi przeglądarkami internetowymi podczas odtwarzania obciążenia.

Podejście oczywiście wymaga ton więcej sprzętu niż zwykłych technik testowania obciążenia, ale sprzęt jest dość tanie, jeśli używasz cloud computing. Przyjemnym efektem ubocznym jest to, że skryptowanie jest znacznie łatwiejsze niż normalne testowanie obciążenia. Nie musisz wykonywać żadnych zaawansowanych dopasowań wyrażeń regularnych (jak wymaga JMeter), aby wyodrębnić pliki cookie, stan sesji .NET, parametry żądania Ajax itp. Ponieważ używasz prawdziwych przeglądarek, po prostu robią to, co powinny.

Przepraszam, że rażąco rzucam na produkt komercyjny, ale mam nadzieję, że ta koncepcja jest interesująca dla niektórych osób i przynajmniej każe im myśleć o nowych sposobach radzenia sobie z testowaniem obciążenia, gdy masz dostęp do szeregu dodatkowego sprzętu!

Użyłem JMeter . Oprócz testowania serwera WWW możesz również przetestować zaplecze bazy danych, usługi przesyłania wiadomości i serwery e-mail.

ab , oblężenie , Tsung , httperf , Trample , Pylot, prośba-log-analizator , perftools

Dla prostego użycia, perfer ab (test porównawczy apache) i oblężenie, później jest potrzebny, ponieważ ab nie obsługuje plików cookie i tworzyłby niekończące się sesje z dynamicznej strony.

oba są łatwe do uruchomienia:

ab -c n -t 30 url

siege -b -c n -t 30s url

oblężenie może przebiegać z większą liczbą adresów URL.

ostatnia wersja oblężenia włącza pełne siegerc, co jest denerwujące. możesz go wyłączyć tylko poprzez edycję tego pliku ( /usr/local/etc/siegerc).

W przypadku usługi internetowej sprawdź loader.io .

Podsumowanie:

loader.io to bezpłatna usługa testowania obciążenia, która umożliwia testowanie warunków skrajnych aplikacji internetowych / apis za pomocą tysięcy jednoczesnych połączeń.

Mają także interfejs API .

Ponieważ to pytanie jest wciąż otwarte, równie dobrze mogę się zastanowić.

Dobrą wiadomością jest to, że w ciągu ostatnich 5 lat narzędzia Open Source naprawdę dojrzały i wystartowały w kosmos, zła wiadomość jest taka, że ​​jest ich tak wiele.

Oto moje myśli: -

Jmeter vs Grinder

Jmeter jest oparty na specyfikacji stylu XML, która jest zbudowana za pomocą GUI.

Grinder korzysta ze skryptów Jython w ramach wielowątkowej architektury Java, więc jest bardziej zorientowany na programistów.

Oba narzędzia będą obsługiwać HTTP i HTTPS i będą miały rejestrator proxy, aby zacząć. Oba narzędzia wykorzystują model kontrolera do sterowania wieloma agentami testowymi, więc skalowalność nie stanowi problemu (biorąc pod uwagę dostęp do chmury).

Co jest lepsze: -

Trudne wezwanie, ponieważ krzywa uczenia się jest stroma przy użyciu obu narzędzi, gdy wchodzisz w bardziej skomplikowane wymagania skryptowe dotyczące przepisywania adresów URL, korelacji, dostarczania unikalnych danych dla każdego użytkownika wirtualnego i symulacji po raz pierwszy lub powracających użytkowników (poprzez manipulowanie nagłówkami HTTP).

Powiedziałem, że zacznę od Jmeter, ponieważ to narzędzie ma ogromną rzeszę fanów i istnieje wiele przykładów i samouczków w Internecie na temat korzystania z tego narzędzia. Jeśli i kiedy dojdziesz do „bloku drogowego”, jest to coś, czego nie możesz „łatwo” zrobić z Jmeter, to spójrz na Grinder. Dobra wiadomość jest taka, że ​​oba te narzędzia mają takie same wymagania Java, a rozwiązanie typu „mieszaj i dopasowuj” nie jest wykluczone.

Coś nowego do dodania - przeglądarki bezgłowe obsługujące wiele instancji Selenium WebDriver.

Jest to stosunkowo nowe podejście, ponieważ opiera się na dostępności zasobów, które można teraz udostępnić z chmury. Przy takim podejściu pobierany jest skrypt Selenium (WebDriver) i uruchamiany w bezgłowej przeglądarce (tj. WebDriver = New HtmlUnitDriver ()) w wielu wątkach.

Z doświadczenia wynika, że ​​z Amazon M1 Small Instance można wykonać około 25 instancji „przeglądarek bezgłowych”.

Oznacza to, że wszystkie problemy z korelacją i przepisywaniem adresów URL znikają po zmianie przeznaczenia skryptów testowania funkcjonalnego na skrypty testowania wydajności.

Skalowalność jest zagrożona, ponieważ więcej maszyn wirtualnych będzie potrzebnych do sterowania obciążeniem, w porównaniu ze sterownikiem HTTP, takim jak Grinder lub Jmeter. To powiedziawszy, jeśli chcesz prowadzić 500 wirtualnych użytkowników, to dzięki 20 małym instancjom Amazon (6 centów za godzinę) przy koszcie zaledwie 1,20 USD za godzinę daje obciążenie bardzo zbliżone do rzeczywistego doświadczenia użytkownika.

Istnieje również niesamowity rozproszony i skalowalny szkielet szarańczy oparty na otwartym kodzie źródłowym, który wykorzystuje greenlety . Świetnie nadaje się do symulacji ogromnej liczby jednoczesnych użytkowników.

Niedawno zaczęliśmy używać Gatling do testowania obciążenia. Zdecydowanie polecam wypróbowanie tego narzędzia do testowania obciążenia. W przeszłości używaliśmy SOASTA i JMETER. Nasz główny powód do rozważenia Gatling jest następujący:

• Rejestrator do nagrywania scenariusza
• Korzystanie z Akka i Netty, które daje lepszą wydajność w porównaniu z modelem Jmeter Threading
• DSL Scala, który jest bardzo łatwy w utrzymaniu w porównaniu do Jmeter XML
• Łatwe pisanie testów, nie przestraszyć, jeśli to Scala.
• Raportowanie

Pozwól, że podam prosty przykład pisania kodu za pomocą Gatling Code:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Możesz jednak uczynić to tak skomplikowanym, jak to możliwe. Jedną z cech wyróżniających Gatling jest bardzo szczegółowe raportowanie.

Oto kilka linków: Samouczek
Gatling
Gatling

Niedawno wygłosiłem na ten temat dyskusję, możesz przejść tutaj:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

To stare pytanie, ale myślę, że warto wspomnieć o nowszych rozwiązaniach. Kasa LoadImpact: http://www.loadimpact.com .

Próbowałem WebLoad to całkiem fajne narzędzie. Jest wyposażony w i przetestuj IDE skryptu, który pozwala nagrywać działania użytkownika na stronie internetowej. Rysuje również wykres podczas przeprowadzania testu warunków skrajnych na serwerze WWW. Wypróbuj, bardzo polecam.

Próbując wszystkich wymienionych tutaj, znalazłem curl-loader jako najlepszy do moich celów. bardzo prosty interfejs, monitorowanie w czasie rzeczywistym, przydatne statystyki, z których buduję wykresy wydajności. Wszystkie funkcje libcurl są włączone.

Blaze meter ma chromowane rozszerzenie do nagrywania sesji i eksportowania ich do JMeter (obecnie wymaga zalogowania). Możesz również zapłacić im pieniądze, aby uruchomić je na klastrze serwerów JMeter (ich ceny wydają się znacznie lepsze niż LoadImpact, z którego właśnie przestałem korzystać):

• BlazeMeter Chrome Extension
• Wpis na blogu na ten temat

Nie mam z nimi żadnego związku, po prostu podoba mi się ich serwis, chociaż nie korzystałem jeszcze z wersji płatnej.

Zadałeś to pytanie prawie rok temu i nie wiem, czy nadal szukasz innego sposobu na przetestowanie swojej witryny. Ponieważ jednak to pytanie nadal nie jest oznaczone jako rozwiązane, chciałbym zasugerować bezpłatną usługę internetową LoadImpact (btw. Niepowiązaną ). Właśnie dostałem ten link za pośrednictwem Twittera i chciałbym udostępnić to znalezisko. Zapewniają dość dobry przegląd, a za kilka dolców dostajesz „tryb pełnego uderzenia”. To prawdopodobnie brzmi dziwnie, ale powodzenia pchanie i hamowanie usługi :)

Uważam, że IBM Page Detailer to także interesujące narzędzie do pracy.

Użyłem openSTA .

Umożliwia to nagrywanie sesji z witryną internetową, a następnie odtwarzanie przy użyciu stosunkowo prostego języka skryptowego.

Możesz łatwo testować usługi sieciowe i pisać własne skrypty.

Umożliwia składanie skryptów razem w dowolny sposób i konfigurowanie liczby iteracji, liczby użytkowników w każdej iteracji, czasu rozruchu do wprowadzenia każdego nowego użytkownika oraz opóźnienia między każdą iteracją. Testy można również zaplanować w przyszłości.

Jest to oprogramowanie typu open source i bezpłatne.

Tworzy szereg raportów, które można zapisać w arkuszu kalkulacyjnym. Następnie używamy tabeli przestawnej do łatwej analizy i wykresu wyników.

Używamy wspomnianego narzędzia Microsoft - Microsoft Stress Tool Application. To najłatwiejsze narzędzie, jakiego użyłem. Jest ograniczony na wiele sposobów, w tym możliwość trafienia tylko do portu 80 podczas ręcznie utworzonych testów. Ale jego łatwość użycia oznacza, że ​​faktycznie się przyzwyczaja.

Uzupełniamy obciążenie tego narzędzia innymi narzędziami, w tym OpenSTA i pająkami do sprawdzania linków.

JMeter wygląda dobrze od mojej początkowej oceny, mam nadzieję, że włączę go do naszej ciągłej integracji w przyszłości. Ale JMeter jest złożony i nie jest trywialny do wdrożenia.

Sugerowałbym otwarcie kolejnego pytania dotyczącego interpretacji wyników narzędzia stresu stwardnienia rozsianego.

Visual Studio Test Edition 2010 (również dobry 2008). Jest to naprawdę łatwe i wydajne narzędzie do tworzenia testów sieci / ładowania.

Dodatkową zaletą tego narzędzia podczas korzystania z serwerów Windows jest zintegrowany dostęp do wszystkich statystyk serwera perfmon w raporcie. Naprawdę użyteczne.

Kolejną zaletą jest to, że z projektem Visual Studio możesz zintegrować „Sesję wydajności”, która profiluje wykonanie kodu Twojej witryny.

Jeśli podajesz strony internetowe z serwera Windows, jest to najlepsze dostępne narzędzie.

Jednak aby załadować test aplikacji, należy użyć osobnej i kosztownej licencji.

Opracowaliśmy proces, który traktuje pomiar obciążenia i wydajności jako pierwszorzędny problem - jak pan mówi, pozostawienie go do końca projektu może prowadzić do rozczarowania ...

Dlatego podczas opracowywania uwzględniamy bardzo podstawowe testy dla wielu użytkowników (przy użyciu selenu), które sprawdzają podstawowe szaleństwo, takie jak zarządzanie przerwanymi sesjami, oczywiste problemy z współbieżnością i oczywiste problemy z rywalizacją o zasoby. Nietrywialne projekty uwzględniają to w procesie ciągłej integracji, dlatego otrzymujemy bardzo regularne informacje zwrotne.

W przypadku projektów, które nie mają ekstremalnych wymagań dotyczących wydajności, w naszych testach uwzględniamy podstawowe testy wydajności; zwykle testujemy testy za pomocą BadBoy i importujemy je do JMeter, zastępując dane logowania i inne elementy specyficzne dla wątku. Następnie zwiększamy je do poziomu, w którym serwer obsługuje 100 żądań na sekundę; jeśli czas reakcji jest krótszy niż 1 sekunda, zwykle wystarcza. Rozpoczynamy i kontynuujemy życie.

W przypadku projektów o ekstremalnych wymaganiach wydajnościowych nadal używamy BadBoy i JMeter, ale wkładamy dużo energii w zrozumienie wąskich gardeł na serwerach na naszym stanowisku testowym (zazwyczaj serwery sieciowe i bazy danych). Istnieje dobre narzędzie do analizy dzienników zdarzeń Microsoft które bardzo w tym pomaga. Zwykle znajdujemy nieoczekiwane wąskie gardła, które w miarę możliwości optymalizujemy; daje nam to aplikację tak szybką, jak to tylko możliwe na „1 serwerze WWW, 1 serwerze bazy danych”. Następnie zwykle wdrażamy naszą docelową infrastrukturę i używamy jednej z usług „Jmeter in the cloud”, aby ponownie uruchomić testy na dużą skalę.

Ponownie raporty PAL pomagają analizować to, co wydarzyło się podczas testów - często występują bardzo różne wąskie gardła w środowiskach produkcyjnych.

Kluczem jest upewnienie się, że nie tylko przeprowadzasz testy warunków skrajnych, ale także gromadzisz informacje potrzebne do zrozumienia wydajności aplikacji.

Wspomniano tutaj wiele dobrych narzędzi. Zastanawiam się, czy narzędzia są odpowiedzią na pytanie: „Jak testujesz aplikację internetową w warunkach skrajnych?” Narzędzia tak naprawdę nie zapewniają metody obciążania aplikacji sieci Web. Oto co wiem:

Testy warunków skrajnych pokazują, jak zawodzi aplikacja internetowa, wyświetlając odpowiedzi na rosnącą populację użytkowników. Testy warunków skrajnych pokazują, jak działa aplikacja internetowa, gdy zawiedzie. Obecnie większość aplikacji internetowych - zwłaszcza aplikacje społecznościowe / mobilne - to integracja usług. Na przykład, kiedy Facebook przestał działać w maju 2011 r., Nie można było zalogować się do aplikacji internetowej Pepsi.com. Aplikacja nie zawiodła całkowicie, tylko duża część jej normalnej funkcji stała się niedostępna dla użytkowników.

Testy wydajności pokazują zdolność aplikacji sieci Web do utrzymania czasów odpowiedzi niezależnie od liczby użytkowników jednocześnie korzystających z aplikacji. Na przykład aplikacja obsługująca 10 transakcji na sekundę z 10 równoczesnymi użytkownikami powinna obsługiwać 20 transakcji na sekundę przy 20 użytkownikach. Jeśli aplikacja obsługuje mniej niż 20 transakcji na sekundę, czasy odpowiedzi wydłużają się, a aplikacja nie jest w stanie uzyskać liniowej skalowalności.

Ponadto w powyższym przykładzie liczba transakcji na sekundę powinna dotyczyć tylko udanych operacji testowego przypadku użycia / przepływu pracy. Awarie zwykle zdarzają się w krótszych odstępach czasu i powodują, że pomiar TPS jest zbyt optymistyczny. Awarie są ważne dla testu warunków skrajnych i wydajności, ponieważ generują również obciążenie aplikacji.

Metodologię PushToTest napisałem w Podręczniku użytkownika TestMaker pod adresem http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker jest dostępny w dwóch wersjach: w wersji Open Source (GPL) Community i TestMaker Enterprise (reklama z doskonałym profesjonalnym wsparciem).

-Szczery

Spójrz na LoadBooster ( https://www.loadbooster.com ). Wykorzystuje bezgłową skryptowalną przeglądarkę PhantomJS / CasperJs do testowania stron internetowych. Phantomjs parsuje i renderuje każdą stronę, wykonuje skrypt po stronie klienta. Bezgłowe podejście do przeglądarki jest łatwiejsze do pisania scenariuszy testowych do obsługi złożonej aplikacji AJAX Heavy Web 2.0, nawigacji w przeglądarce, klikania myszą i naciskania klawiszy w przeglądarce lub czekania, aż element będzie istniał w DOM. LoadBooster obsługuje również skrypt selenu HTML.

Uwaga: Pracuję dla LoadBooster.

Wypróbuj ZebraTester, który jest znacznie łatwiejszy w użyciu niż jMeter. Używałem jMeter od dłuższego czasu, ale całkowity czas konfiguracji testu obciążenia zawsze był problemem. Chociaż ZebraTester nie jest oprogramowaniem typu open source, nadrabia to czas, który zaoszczędziłem w ciągu ostatnich sześciu miesięcy. Mają także portal SaaS, który można wykorzystać do szybkiego uruchamiania testów przy użyciu generatorów obciążenia.

Jeszcze jedna uwaga, w przypadku naszej aplikacji internetowej odkryłem, że mieliśmy ogromne problemy z wydajnością z powodu sprzeczności między wątkami o zamki ... więc morałem było bardzo staranne przemyślenie schematu blokowania. Skończyło się na tym, że wątki robocze dławiły zbyt wiele żądań za pomocą asynchronicznej procedury obsługi http, w przeciwnym razie aplikacja zostałaby po prostu przytłoczona i uległa awarii. Oznaczało to, że ogromne zaległości mogą się gromadzić, ale przynajmniej strona pozostanie niezadowolona.

Spójrz na TestComplete .

Popieram propozycję opensta. Chciałbym tylko dodać, że pozwala ci robić rzeczy, aby monitorować serwer, który testujesz za pomocą SMTP. Śledzimy obciążenie procesora, używaną pamięć, wysłane bajty itp. Jedynym minusem jest to, że jeśli znajdziesz coś boken i chcesz naprawić, zależy on od kilku bibliotek open source, które nie są już utrzymywane, więc kompilacja wersja źródła jest trudniejsza niż w większości OSS.

Grałem z JMeter. Jedna myśl, że nie można nie przetestować, to formularze internetowe ASP.NET. Stanowisko przełamało moje testy. Nie jestem pewien, dlaczego, ale istnieje kilka narzędzi, które nie obsługują stanu widoku poprawnie. Mój obecny projekt to ASP.NET MVC i JMeter dobrze z nim współpracuje.

Miałem dobre wyniki z FunkLoad :

• łatwa w obsłudze interakcja użytkownika
• raporty są jasne
• może monitorować obciążenie serwera

Ryzykując oskarżenie o bezwstydną autopromocję, chciałbym zauważyć, że w swoim poszukiwaniu darmowego narzędzia do testowania obciążenia poszedłem do tego artykułu: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

Albo nie mogłem uzyskać żądanej przepustowości, albo nie mogłem uzyskać elastyczności, jakiej chciałem. I chciałem łatwo agregować wyniki hostów generujących wiele testów obciążenia w analizie po teście.

Wypróbowałem wszystkie narzędzia z listy i ku mojej frustracji odkryłem, że żadne z nich nie zrobiło tego, co chciałem być w stanie zrobić. Więc zbudowałem jeden i udostępniam go.

Oto on: http://sourceforge.net/projects/loadmonger

PS: Żadnych złośliwych komentarzy do nazwiska od ludzi znających slang miejski. Nie byłem, ale teraz jestem trochę bardziej światowy.

Głosuję również na jMeter i chcę dodać cytaty do odpowiedzi @PeterBernier.

Główne pytanie, na które ładowane są odpowiedzi testowe, to ilu jednoczesnych użytkowników może obsługiwać moja aplikacja internetowa? Aby uzyskać właściwą odpowiedź, testy obciążenia powinny odzwierciedlać rzeczywiste użycie aplikacji, tak blisko jak to możliwe .

Pamiętaj, że jMeter ma wiele elementów składowych Kontrolery logiczne , elementy konfiguracji , procesory wstępne , nasłuchiwania ... które mogą ci w tym pomóc.

Za pomocą jMeter możesz naśladować sytuację w świecie rzeczywistym, na przykład możesz:

1. Konfiguracja jmeter działać jako prawdziwego konfigurując przeglądarkę ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding, ajax support, ...)
2. Konfiguracja JMeter do generowania żądań użytkownika (poprzez określenie number of users per second, ramp-up time, scheduling, ...)
3. Skonfiguruj wiele klientów z jMeter, aby wykonać test obciążenia rozproszonego.
4. Przetwórz odpowiedź, aby sprawdzić, czy serwer odpowiada poprawnie podczas testu. (Na przykład assertodpowiedź, aby znaleźć w nim tekst)

Proszę wziąć pod uwagę:

• Za pomocą jMeter można łatwo rozpocząć prawdziwy test aplikacji internetowej w kilka minut. JMeter ma bardzo łatwe narzędzie, które rejestruje scenariusz testowy (znany jako HTTP(S) Test Script Recorder).
• jMeter ma wiele wtyczek na http://jmeter-plugins.org .
• Interfejs użytkownika jMeter jest oparty na huśtawce i wprowadził dobre zmiany w jMeter 3.2. Z drugiej strony należy wziąć pod uwagę, że interfejs GUI JMeter powinien być używany tylko do testowania i debugowania. Nie jest dobrą praktyką używanie go w trybie GUI do rzeczywistego testu. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Skonfiguruj i przetestuj scenariusz i uruchom go w trybie innym niż GUI.
• Wiele raportów pokazuje narzędzia w jMeter (znane jako listeners), ale nie powinny być włączone podczas testu. Musisz uruchomić test i wygenerować raporty ( .jtlpliki). Następnie musisz użyć tych narzędzi do analizy wyników. Proszę spojrzeć na https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats lub https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

Https://www.blazemeter.com/jmeter ma bardzo dobre i praktyczne wskazówki, które pomogą Ci skonfigurować środowisko testowe.