Apache Bench - Szybki przewodnik
Testy wydajności okazały się kluczowe dla sukcesu firmy. Witryna o niskiej wydajności nie tylko ponosi straty finansowe, ale może również czasami prowadzić do konsekwencji prawnych.
Nikt nie chce znosić wolno działającej, zawodnej witryny w ważnych interakcjach online, takich jak zakupy, wykonywanie testów online, opłacanie rachunków itp. Przy tak szerokiej dostępności Internetu, wachlarz alternatyw jest ogromny. Łatwiej jest stracić klientów niż ich zdobyć, a wydajność jest kluczowym elementem zmieniającym zasady gry.
Potrzeba narzędzia do testowania obciążenia
Jeśli zrozumiemy, jaka jest potrzeba narzędzia do testowania obciążenia, da nam to powód i motywację do jego użycia. Niektóre znane witryny biznesowe przeżywały poważne przestoje z powodu dużej liczby odwiedzających. Witryny e-commerce dużo inwestują w kampanie reklamowe, ale nie w testowanie obciążenia. Dlatego nie zapewniają optymalnej wydajności systemu, gdy ten marketing przyciąga ruch.
Innym znanym przykładem ignorowania testów obciążenia jest „błąd podczas nawiązywania połączenia” w witrynach WordPress. Dlatego warto przetestować stronę internetową lub aplikację przed jej wdrożeniem w środowisku produkcyjnym. Dobrze jest szybko ustalić najlepszy scenariusz projektu przed przeprowadzeniem bardziej szczegółowych testów w przyszłości.
Co to jest ławka Apache?
Apache Bench (ab) to narzędzie organizacji Apache do testowania porównawczego serwera internetowego Hypertext Transfer Protocol (HTTP). Chociaż jest przeznaczony do pomiaru wydajności serwera WWW Apache, może być również używany do testowania dowolnego innego serwera WWW, który jest równie dobry. Dzięki temu narzędziu możesz szybko dowiedzieć się, ile żądań na sekundę Twój serwer WWW jest w stanie obsłużyć.
Funkcje Apache Bench
Zobaczmy ważne funkcje i ograniczenia Apache Bench. Funkcje i ograniczenia są wymienione poniżej -
Będąc oprogramowaniem open source, jest dostępne bezpłatnie.
Jest to prosty program komputerowy wiersza poleceń.
Jest to narzędzie niezależne od platformy. Oznacza to, że równie dobrze można go wywołać na Linux / Unix lub na serwerze Windows.
Może przeprowadzać testy obciążenia i wydajności tylko dla serwera WWW - HTTP lub HTTPS.
Nie można go rozszerzyć.
Apache Bench używa tylko jednego wątku systemu operacyjnego, niezależnie od poziomu współbieżności (określonego przez flagę -c). Dlatego w przypadku testów porównawczych serwerów o dużej pojemności pojedyncza instancja Apache Bench może sama w sobie stanowić wąskie gardło. Aby całkowicie nasycić docelowy adres URL, lepiej jest używać równolegle dodatkowych wystąpień Apache Bench, jeśli serwer ma wiele rdzeni procesorów.
Ostrożność
Należy mieć świadomość, że w Apache Bench nie ma dyrektywy, która zwiększałaby współbieżność w określonych interwałach podczas wykonywania testów. Dlatego uruchamianie testów obciążenia przy użyciu ab jest równoważne z atakiem typu „odmowa usługi” (DOS). Zaleca się poinformowanie i uzyskanie wcześniejszej zgody od dostawcy usług VPS, jeśli zamierzasz przeprowadzać testy dużego obciążenia przez dłuższy czas. Przydzielą ci odpowiedni przedział czasu lub przesuną twój węzeł do zadania testowania obciążenia.
Po drugie, jeśli testujesz witrynę internetową osoby trzeciej w sposób ciągły i przez długi czas tylko po to, aby nauczyć się Apache Bench ze swojego VPS (który staje się węzłem testowym), istnieje zdalna możliwość, że Twój publiczny adres IP VPS może zostać zablokowany przez witrynę trzeciej osoby na stałe. W takim przypadku nie będziesz mógł połączyć się z tą witryną za pomocą tego samego adresu IP. Ale jeśli naprawdę chcesz połączyć się ze stroną internetową w przyszłości, jedynym rozwiązaniem będzie rozmowa z administratorem systemu docelowej strony internetowej lub utworzenie nowej instancji serwera z innym adresem IP z pomocą dostawcy usług VPS.
Po ostrzeżeniu, zapewniam, że wszystkie testy w tym samouczku są wystarczająco bezpieczne i wykraczają poza praktyki, które administratorzy systemów na ogół nazywają „nadużyciami systemu”.
W tym rozdziale poprowadzimy Cię, jak skonfigurować środowisko Apache Bench na serwerze VPS.
Wymagania systemowe
Memory - 128 MB
Disk Space - Brak wymagań minimalnych
Operating System - Brak wymagań minimalnych
Instalowanie Apache Bench
Apache Bench jest samodzielną aplikacją i nie ma żadnych zależności od instalacji serwera WWW Apache. Poniżej przedstawiono dwuetapowy proces instalacji Apache Bench.
Step 1 - Zaktualizuj bazę danych pakietów.
# apt-get updateZwróć uwagę, że symbol # przed poleceniem terminala oznacza, że użytkownik root wydaje to polecenie.
Step 2 - Zainstaluj pakiet narzędzi apache2, aby uzyskać dostęp do Apache Bench.
# apt-get install apache2-utilsApache Bench jest teraz zainstalowany. Jeśli chcesz przetestować aplikację internetową hostowaną na tym samym VPS, wystarczy zainstalować tylko serwer WWW Apache -
# apt-get install apache2Będąc narzędziem Apache, Apache Bench jest automatycznie instalowane podczas instalacji serwera WWW Apache.
Weryfikacja instalacji Apache Bench
Zobaczmy teraz, jak zweryfikować instalację Apache Bench. Poniższy kod pomoże zweryfikować instalację -
# ab -VOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/Kiedy zobaczysz powyższe dane wyjściowe terminala, oznacza to, że pomyślnie zainstalowałeś Apache Bench.
Tworzenie uprzywilejowanego użytkownika Sudo
Z punktu widzenia bezpieczeństwa uważa się, że dobrą praktyką dla administratora systemu jest utworzenie użytkownika sudo zamiast pracy jako root. Stworzymy użytkownika testowego, nazwanego test, w celu -
# useradd -m -d /home/test -g sudo testUstawmy hasło dla nowego użytkownika -
# passwd testSystem poprosi o nowe hasło do testu użytkownika. Możesz wprowadzić proste hasło, ponieważ tylko testujemy, a nie wdrażamy na serwerze produkcyjnym. Zwykle polecenie sudo monituje o podanie hasła użytkownika sudo; zaleca się, aby nie używać skomplikowanego hasła, ponieważ proces staje się uciążliwy.
Output
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfullyTestowanie strony Apache.org
W tej sekcji przetestujemy witrynę Apache.org. Przejdźmy najpierw do testu użytkownika sudo -
# su testNa początek przetestujemy stronę organizacji Apache, https://www.apache.org/. Najpierw uruchomimy polecenie, a następnie zrozumiemy dane wyjściowe -
$ ab -n 100 -c 10 https://www.apache.org/Tutaj -nto liczba żądań do wykonania podczas sesji testów porównawczych. Domyślnie wykonuje się tylko jedno żądanie, co zwykle prowadzi do niereprezentatywnych wyników testów porównawczych.
I -cjest współbieżnością i oznacza liczbę wielu żądań do wykonania jednocześnie. Domyślnie jest to jedno żądanie na raz.
Zatem w tym teście Apache Bench wyśle 100 żądań z współbieżnością 10 do serwera organizacji Apache.
Output
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path: /
Document Length: 58769 bytes
Concurrency Level: 10
Time taken for tests: 1.004 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5911100 bytes
HTML transferred: 5876900 bytes
Requests per second: 99.56 [#/sec] (mean)
Time per request: 100.444 [ms] (mean)
Time per request: 10.044 [ms] (mean, across all concurrent requests)
Transfer rate: 5747.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 39 46 30.9 41 263
Processing: 37 40 21.7 38 255
Waiting: 12 15 21.7 13 230
Total: 77 86 37.5 79 301
Percentage of the requests served within a certain time (ms)
50% 79
66% 79
75% 80
80% 80
90% 82
95% 84
98% 296
99% 301
100% 301 (longest request)Po uruchomieniu naszego pierwszego testu łatwo będzie rozpoznać wzorzec użycia tego polecenia, który jest następujący:
# ab [options .....] URLgdzie,
ab - Polecenie Apache Bench
options - flagi dla konkretnego zadania, które chcemy wykonać
URL - adres URL ścieżki, którą chcemy przetestować
Zrozumienie wartości wyjściowych
Musimy zrozumieć różne metryki, aby zrozumieć różne wartości wyjściowe zwracane przez ab. Oto lista -
Server Software - Jest to nazwa serwera WWW zwrócona w nagłówku HTTP pierwszego udanego powrotu.
Server Hostname - Jest to adres DNS lub IP podany w linii poleceń.
Server Port- Jest to port, z którym łączy się ab. Jeśli w wierszu poleceń nie zostanie podany żaden port, wartość domyślna to 80 dla http i 443 dla https.
SSL/TLS Protocol- jest to parametr protokołu negocjowany między klientem a serwerem. Zostanie wydrukowane tylko wtedy, gdy używany jest SSL.
Document Path - To jest identyfikator URI żądania przeanalizowany z ciągu wiersza poleceń.
Document Length- Jest to rozmiar w bajtach pierwszego pomyślnie zwróconego dokumentu. Jeśli długość dokumentu zmienia się podczas testowania, odpowiedź jest uważana za błąd.
Concurrency Level - Jest to liczba jednoczesnych klientów (odpowiednik przeglądarek internetowych) używanych podczas testu.
Time Taken for Tests - Jest to czas od momentu utworzenia pierwszego połączenia przez gniazdo do momentu odebrania ostatniej odpowiedzi.
Complete Requests - liczba otrzymanych pomyślnych odpowiedzi.
Failed Requests- liczba żądań uznanych za niepowodzenie. Jeśli liczba jest większa od zera, zostanie wydrukowany inny wiersz zawierający liczbę żądań, które nie powiodły się z powodu połączenia, odczytu, nieprawidłowej długości treści lub wyjątków.
Total Transferred- całkowita liczba bajtów odebranych z serwera. Ta liczba jest w zasadzie liczbą bajtów przesłanych przez kabel.
HTML Transferred- Całkowita liczba bajtów dokumentów odebranych z serwera. Ta liczba nie obejmuje bajtów odebranych w nagłówkach HTTP
Requests per second- To jest liczba żądań na sekundę. Ta wartość jest wynikiem podzielenia liczby żądań przez łączny czas potrzebny.
Time per request- średni czas spędzony na żądanie. Pierwsza wartość jest obliczana za pomocą formuły współbieżność * czas podjęte * 1000 / zrobione, a druga wartość jest obliczona według formuły czas podjęte * 1000 / gotowe
Transfer rate - Stawka transferu wyliczona według wzoru totalread / 1024 / timesaken.
Szybka analiza wyników testu obciążenia
Dowiedziawszy się o nagłówkach wartości wyjściowych z polecenia ab, spróbujmy przeanalizować i zrozumieć wartości wyjściowe dla naszego początkowego testu -
Organizacja Apache używa własnego oprogramowania serwera WWW - Apache (wersja 2.4.7)
Serwer nasłuchuje na porcie 443 z powodu protokołu HTTPS. Gdyby to był http, byłoby to 80 (domyślnie).
Łączna liczba przesłanych danych to 58769 bajtów na 100 żądań.
Test zakończony w 1,004 sekundy. Brak nieudanych żądań.
Żądania na sekundę - 99,56. Uważa się, że jest to całkiem dobra liczba.
Czas na żądanie - 100,444 ms (dla 10 jednoczesnych żądań). Zatem dla wszystkich żądań jest to 100,444 ms / 10 = 10,044 ms.
Szybkość przesyłania - odebrano 1338,39 [KB / s].
W statystykach czasu połączeń można zauważyć, że wiele żądań musiało czekać kilka sekund. Może to być spowodowane ustawieniem przez serwer WWW Apache żądań w kolejce oczekiwania.
W naszym pierwszym teście przetestowaliśmy aplikację (tj. Www.apache.org) hostowaną na innym serwerze. W dalszej części samouczka będziemy testować nasze przykładowe aplikacje internetowe hostowane na tym samym serwerze, z którego będziemy przeprowadzać testy ab. Ma to na celu ułatwienie nauki i demonstrację. Idealnie, aby uzyskać dokładny pomiar, węzeł główny i węzeł testowy powinny być różne.
Aby lepiej nauczyć się ab, powinieneś porównać i obserwować, jak wartości wyjściowe zmieniają się w różnych przypadkach, w miarę postępów w tym samouczku.
Wykreślanie danych wyjściowych Apache Bench
Tutaj wykreślimy odpowiedni wynik, aby zobaczyć, ile czasu zajmuje serwer w miarę wzrostu liczby żądań. W tym celu dodamy-g opcja w poprzednim poleceniu, po której następuje nazwa pliku (tutaj out.data), w którym zostaną zapisane dane wyjściowe ab -
$ ab -n 100 -c 10 -g out.data https://www.apache.org/Zobaczmy teraz out.data zanim utworzymy działkę -
$ less out.dataOutput
starttime seconds ctime dtime ttime wait
Tue May 30 12:11:37 2017 1496160697 40 38 77 13
Tue May 30 12:11:37 2017 1496160697 42 38 79 13
Tue May 30 12:11:37 2017 1496160697 41 38 80 13
...Przyjrzyjmy się teraz nagłówkom kolumn w out.data plik -
starttime - To jest data i godzina rozpoczęcia rozmowy.
seconds - To samo co starttime, ale w uniksowym formacie timestamp (data -d @ 1496160697 zwraca wyjście starttime).
ctime - To jest czas połączenia.
dtime - To jest czas przetwarzania.
ttime - To jest czas całkowity (jest to suma czasu ctime i dtime, matematycznie ttime = ctime + dtime).
wait - To jest czas oczekiwania.
Aby uzyskać obrazową wizualizację tego, jak te wiele elementów są ze sobą powiązane, spójrz na poniższy obraz -
Jeśli pracujemy nad terminalem lub gdzie grafika nie jest dostępna, gnuplotto świetna opcja. Szybko to zrozumiemy, wykonując następujące kroki.
Pozwól nam zainstalować i uruchomić gnuplot -
$ sudo apt-get install gnuplot
$ gnuplotOutput
G N U P L O T
Version 4.6 patchlevel 6 last modified September 2014
Build System: Linux x86_64
Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others
gnuplot home: http://www.gnuplot.info
faq, bugs, etc: type "help FAQ"
immediate help: type "help" (plot window: hit 'h')
Terminal type set to 'qt'
gnuplot>Kiedy pracujemy nad terminalem i zakładając, że grafika nie jest dostępna, możemy wybrać głupi terminal, który będzie dawał dane wyjściowe w ASCII na samym terminalu. To pomaga nam zorientować się, jak wygląda nasza fabuła za pomocą tego szybkiego narzędzia. Przygotujmy teraz terminal do kreślenia ASCII.
gnuplot> set terminal dumbOutput
Terminal type set to 'dumb'
Options are 'feed size 79, 24'Ponieważ nasz terminal gnuplot jest teraz gotowy do kreślenia ASCII, wykreślmy dane z pliku out.data plik -
gnuplot> plot "out.data" using 9 w lOutput
1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
+ + + + + + +"out.data" using 9 ****** +
| |
1200 ++ ********************************************
| ******************* |
1000 ++ * ++
| * |
| * |
800 ++ * ++
| * |
| * |
600 ++ * ++
| * |
| * |
400 ++ * ++
| * |
200 ++ * ++
| * |
+**** + + + + + + + + + +
0 ++-----+------+-----+------+------+------+------+-----+------+-----++
0 10 20 30 40 50 60 70 80 90 100Wykreśliliśmy ttime, czas całkowity (w ms) z kolumny 9 w odniesieniu do liczby żądań. Możemy zauważyć, że w pierwszych dziesięciu wniosków, całkowity czas był w prawie 100 ms, przez 30 kolejnych wniosków (od 10 th do 40 th ), wzrosła do 1100 ms, i tak dalej. Twoja fabuła musi się różnić w zależności od twojegoout.data.
W poprzednim rozdziale zrozumieliśmy podstawowe użycie Apache Bench do testowania strony internetowej innej firmy. W tej sekcji użyjemy tego narzędzia do przetestowania aplikacji internetowej na naszym własnym serwerze. Aby w miarę możliwości samouczek był niezależny, zdecydowaliśmy się zainstalować aplikację w języku Python w celach demonstracyjnych; możesz wybrać dowolny inny język, taki jak PHP lub Ruby, w zależności od poziomu wiedzy.
Instalowanie Pythona
Ogólnie Python jest instalowany domyślnie na serwerach Linux.
Instalowanie Bottle Framework i tworzenie prostej aplikacji
Bottle to mikro-framework napisany w Pythonie do tworzenia aplikacji internetowych, a pip to menedżer pakietów w Pythonie. Wpisz następujące polecenie w terminalu, aby zainstalować butelkę -
$ sudo apt-get install python-pip
$ sudo pip install bottleStwórzmy teraz małą aplikację Butelka. W tym celu utwórz katalog i przejdź do niego -
$ mkdir webapp
$ cd webappStworzymy nowy skrypt w Pythonie, app.py, w katalogu webapp -
$ vim app.pyTeraz napisz następujący kod w pliku app.py -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = 'localhost', port = 8080)Po dodaniu powyższych wierszy zapisz i zamknij plik. Po zapisaniu pliku możemy uruchomić skrypt w języku Python, aby uruchomić aplikację -
$ python app.pyOutput
Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.Te dane wyjściowe pokazują, że nasza aplikacja działa na komputerze lokalnym na hoście http://localhost i nasłuchując w porcie 8080.
Sprawdźmy, czy nasza aplikacja poprawnie reaguje na żądania HTTP. Ponieważ ten terminal nie może przyjmować żadnych danych bez zakończenia obsługi aplikacji Butelka, musimy zalogować się do naszego VPS za pomocą innego terminala. Po zalogowaniu się do VPS na innym terminalu możesz przejść do swojej aplikacji, wpisując następujący kod w nowym terminalu.
$ lynx http://localhost:8080/Lynx to przeglądarka wiersza poleceń i jest zwykle instalowana domyślnie w różnych dystrybucjach Linuksa, takich jak Debian i Ubuntu. Jeśli zobaczysz następujące dane wyjściowe, oznacza to, że Twoja aplikacja działa poprawnie.
Output
Jeśli widzisz powyższe dane wyjściowe, oznacza to, że nasza aplikacja jest aktywna i gotowa do testów.
Testowanie aplikacji za pomocą rozwojowego serwera internetowego
Należy pamiętać, że program ab zawiera błąd i nie jest w stanie przetestować aplikacji na hoście lokalnym. Więc zmienimy hosta z localhost na 127.0.0.1 w pliku app.py. Więc plik zmieni się na następujący -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = '127.0.0.1', port = 8080)Przetestujmy teraz naszą aplikację, wpisując następującą komendę na tym samym terminalu, na którym uruchomiono polecenie lynx -
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.203 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 16500 bytes
HTML transferred: 1200 bytes
Requests per second: 493.78 [#/sec] (mean)
Time per request: 20.252 [ms] (mean)
Time per request: 2.025 [ms] (mean, across all concurrent requests)
Transfer rate: 79.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 6 28.2 2 202
Waiting: 1 6 28.2 2 202
Total: 1 6 28.2 2 202
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 202
99% 202
100% 202 (longest request)Podczas gdy wyjście na pierwszym terminalu będzie (100 razy) w następujący sposób -
...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12
...Możesz obserwować, jak różne wartości wyniku ab zmieniły się w porównaniu z początkowym testem.
Testowanie aplikacji na wielowątkowym serwerze internetowym
W poprzednich testach ab korzystaliśmy z domyślnego serwera WWW zawartego we frameworku Bottle.
Teraz zmienimy jednowątkowy domyślny serwer WWW na wielowątkowy. Dlatego zainstalujmy wielowątkową bibliotekę serwera WWW, taką jakcherrypy lub gunicorni powiedz Butelce, żeby go użył. Wybraliśmy gunicorn do celów demonstracyjnych tutaj (możesz też wybrać inny) -
$ sudo apt-get install gunicornI zmodyfikuj plik, czyli zmień domyślny serwer WWW na gunicorn -
...
run(server = 'gunicorn'...)
...Przetestujmy aplikację na drugim terminalu.
$ ab -n 100 -c 10 http://127.0.0.1:8080/helloOutput
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: gunicorn/19.0.0
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.031 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17200 bytes
HTML transferred: 1200 bytes
Requests per second: 3252.77 [#/sec] (mean)
Time per request: 3.074 [ms] (mean)
Time per request: 0.307 [ms] (mean, across all concurrent requests)
Transfer rate: 546.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 4
Processing: 1 2 0.7 3 4
Waiting: 0 2 0.8 2 3
Total: 2 3 0.6 3 5
WARNING: The median and mean for the initial connection time are not within a normal
deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 5
98% 5
99% 5
100% 5 (longest request)Zwróć uwagę, jak liczba żądań na sekundę wzrosła z 493 do 3252. Oznacza to, że gunicorn nadaje się jako serwer produkcyjny dla aplikacji Pythona.
W tym rozdziale dowiemy się, jak testować wiele adresów URL jednocześnie. W tym celu będziemy musieli edytować nasz plik aplikacji app.py, aby zawierał dwa adresy URL -
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello1')
def hello():
return "Hello World! It is first URL."
@app.route('/hello2')
def hello():
return "Hello World! It is second URL."
run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)Tworzenie prostego skryptu powłoki
Możesz to zrobić, tworząc skrypt powłoki z wieloma wywołaniami ab. Utwórz plik test.sh i dodaj do niego następujące wiersze -
ab -n 100 -c 10 http://127.0.0.1:8080/hello1
ab -n 100 -c 10 http://127.0.0.1:8080/hello2Po dodaniu powyższych wierszy zapisz i zamknij plik. Spraw, aby plik był wykonywalny -
chmod u+x test.shUruchommy teraz skrypt -
./test.shAby uniknąć powtórzeń i przejrzystości, pokażemy tylko istotne dane wyjściowe ab, wskazując kropkami, która część została pominięta, jak poniżej.
Wynik
.
.
.
Document Path: /hello1
Document Length: 732 bytes
Concurrency Level: 10
Time taken for tests: 0.040 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 90000 bytes
HTML transferred: 73200 bytes
Requests per second: 2496.13 [#/sec] (mean)
Time per request: 4.006 [ms] (mean)
Time per request: 0.401 [ms] (mean, across all concurrent requests)
Transfer rate: 2193.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 3
Processing: 1 3 1.0 4 5
Waiting: 0 3 1.2 4 4
Total: 1 4 0.6 4 5
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
.
.
.Skrypt powłoki, aby zapisać dane wyjściowe Apache Bench do pliku
Możesz zapisać dane wyjściowe Apache Bench do pliku, tworząc skrypt powłoki z wieloma wywołaniami ab. Na końcu każdego wiersza umieść plik&;powoduje to, że polecenie działa w tle, a następne polecenie rozpoczyna jego wykonanie. Będziesz także chciał przekierować dane wyjściowe do pliku dla każdego adresu URL za pomocą <nazwa pliku>. Na przykład nasz plik test.sh po modyfikacji będzie wyglądał następująco -
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &Tutaj, test1.txt i test2.txt to pliki do zapisania danych wyjściowych.
Możesz sprawdzić, czy powyższy skrypt utworzył dwa pliki, test1.txt i test2.txt, które zawierają dane wyjściowe ab dla odpowiednich adresów URL -
$ ls -lWynik
...
-rw-r--r-- 1 root root 5225 May 30 12:11 out.data
-rwxr--r-- 1 root root 118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root 91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root 1291 Jun 10 12:31 test2.txt
...Sytuacja uważna
Używając ab, powinieneś być czujny na niepowodzenie testu bez ostrzeżenia. Na przykład, jeśli sprawdzisz zły adres URL, możesz otrzymać coś podobnego do następującego (celowo zmieniliśmy tutaj port).
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:805/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software:
Server Hostname: 127.0.0.1
Server Port: 805
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.002 seconds
Complete requests: 100
Failed requests: 150
(Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests: 0
Total transferred: 0 bytes
HTML transferred: 0 bytes
Requests per second: 44984.26 [#/sec] (mean)
Time per request: 0.222 [ms] (mean)
Time per request: 0.022 [ms] (mean, across all concurrent requests)
Transfer rate: 0.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.2 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.2 0 0
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 0
95% 0
98% 0
99% 0
100% 0 (longest request)W tym rozdziale zrozumiemy przygotowania wymagane do testowania stron dynamicznych. Dynamiczna strona internetowa po stronie serwera to strona internetowa, której konstrukcja jest kontrolowana przez serwer aplikacji przetwarzający skrypty po stronie serwera. Ławka Apache może załadować tylko test dynamicznej strony internetowej po stronie serwera.
Poziom współbieżności i łączna liczba żądań
Poziom współbieżności powinien być niższy niż łączna liczba żądań.
$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Output
ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/pathKorzystanie z flag
W tej sekcji opiszemy użycie niektórych ważnych flag z poleceniem ab. Będziemy używać zamiennie terminów, opcji i flag.
Pełne -v
Opcji pełnej można użyć do analizy i debugowania, jeśli istnieje wiele nieudanych żądań. Typową oznaką niepowodzenia testu obciążenia jest to, że test kończy się bardzo szybko i daje dobrą liczbę żądań na sekundę. Ale będzie to zły punkt odniesienia. Aby zidentyfikować sukces lub porażkę, możesz użyć-v 2opcja, która zrzuci treść i nagłówek każdej odpowiedzi na wyjście terminala. Następujące polecenie przedstawia przypadek użycia -
$ ab -n 1 -v 2 http://www.generic-example-URL.com/Output
LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687Oczywiście, jeśli testujesz zmienne odpowiedzi lub zwracasz kody HTTP inne niż 200 w przypadku jakiegokolwiek błędu, powinieneś po prostu zignorować sprawdzanie długości za pomocą -lopcja. Wkrótce zobaczymy HTTP inny niż 200, kiedy w kolejnych rozdziałach uruchomimy aplikację web2py.
Keep-alive -k
Kiedy klient wysyła żądanie HTTP, nawiązywane jest połączenie z serwerem, serwer wysyła odpowiedź, a po wysłaniu żądania połączenie jest zamykane. Ten cykl jest kontynuowany przy każdym żądaniu. Jednak przy ustawieniu utrzymywania aktywności (nazywanym również połączeniami trwałymi) klient utrzymuje otwarte podstawowe połączenie TCP, aby ułatwić wiele żądań i odpowiedzi; eliminuje to długi i kosztowny czas inicjalizacji połączenia, który w innym przypadku byłby obecny.
Zmienna długość dokumentu -l
Jeśli strona internetowa ma zmienną długość, należy skorzystać z tej opcji -l. Apache Bench nie zgłasza błędów, jeśli długość odpowiedzi nie jest stała. Może to być przydatne w przypadku stron dynamicznych.
Użycie opcji -r
Jak zmusić ab nie wychodzić po otrzymaniu błędów? Powinieneś skorzystać z opcji-r. Bez tej opcji test może zakończyć się niepowodzeniem, gdy tylko żądanie trafi w błąd gniazda. Jednak przy tej opcji błędy będą zgłaszane w nagłówku błędów zakończonych niepowodzeniem, ale test będzie kontynuowany do końca.
Użycie opcji -H
Ta opcja służy do dodawania dowolnego wiersza nagłówka. Argument ma zazwyczaj postać prawidłowego wiersza nagłówka, zawierającego parę pole-wartość rozdzieloną dwukropkami (np. „Accept-Encoding: zip / zop; 8bit”).
Użycie opcji -C
W dalszej części szczegółowo dowiemy się, jak korzystać z powyższych opcji w połączeniu z możliwością wykorzystania wartości cookie, czyli -Copcja. Opcja -C ma zwykle postaćname = valuepara. To pole można powtórzyć.
Używanie Session Cookie z Apache Bench
Aby zrozumieć, jak korzystać z pliku cookie w Apache Bench, potrzebujemy strony internetowej, która próbuje ustawić plik cookie. Bardzo dobrym przykładem jest aplikacja web2py, która jest frameworkiem sieciowym w języku Python.
Instalowanie web2py
Zamierzamy szybko zainstalować kolejną aplikację web2py w języku Python. Możesz przeczytać więcej o tym, jak go używać w Omówieniu struktury Web2py .
Python jest zwykle instalowany domyślnie na serwerze Ubuntu i Debian. Dlatego jeden wymóg jest już spełniony, aby pomyślnie uruchomić web2py.
Musimy jednak zainstalować pakiet unzip, aby wyodrębnić pliki źródłowe web2py z pliku zip, który będziemy pobierać -
$ sudo apt-get update
$ sudo apt-get install unzipPobierzmy framework web2py ze strony projektu. Pobieramy to do naszego folderu domowego -
$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zipTeraz możemy rozpakować pobrany plik i przenieść go do środka -
$ unzip web2py_src.zip
$ cd web2pyAby uruchomić web2py, nie musisz go instalować. Gdy znajdziesz się w katalogu web2py, możesz go uruchomić, wpisując następujące polecenie -
$python web2py.pyJeśli wszystko się powiedzie, zobaczysz następujące dane wyjściowe, w których zostaniesz poproszony o wybranie hasła do interfejsu administracyjnego -
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:
please visit:
http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py serverNależy jednak mieć świadomość, że uruchomiony interfejs WWW jest dostępny tylko na komputerze lokalnym.
Na podstawie danych wyjściowych możesz zrozumieć, że aby zatrzymać serwer WWW, będziesz musiał wpisać „CTRL-C” w terminalu natychmiastowym. Z drugiej strony, aby zatrzymać serwer web2py na innym terminalu związanym z tym samym VPS, można wstawić polecenie kill -SIGTERM <PID>, gdzie <PID> to identyfikator procesu dla serwera web2py, którym w tym przypadku jest 23904.
Plik cookie sesji z web2py
Jeśli strona jest dostępna tylko dla zalogowanego użytkownika, a nie jest dostępna bezpośrednio ze strony logowania, w takim przypadku możesz użyć -Cflaga. Ta flaga definiuje plik cookie dla polecenia ab. Ale musisz uzyskać wartość pliku cookie identyfikatora sesji z ważnej sesji. Jak to zdobyć? Różne samouczki online poprowadzą Cię do narzędzi programistycznych przeglądarki Chrome (lub Mozilla). Ale w naszym przypadku testowym, ponieważ aplikacja jest dostępna tylko w wierszu poleceń, użyjemy przeglądarki lynx, aby uzyskać wartość.
Najpierw pobierzmy wartość cookie sesji. Otwórz inny terminal i wpisz następujące polecenie -
$ lynx http://127.0.0.1:8000/W odpowiedzi na powyższe polecenie lynx zapyta Cię o zgodę na zaakceptowanie pliku cookie z serwera web2py, jak pokazano na poniższym obrazku.
Zanotuj wartość pliku cookie przed wpisaniem yzaakceptować plik cookie. Teraz terminal będzie wyglądał podobnie do poniższego obrazka - strona na terminalu!
Po uzyskaniu wartości cookie uruchomimy teraz test ab. W tym celu będziemy musieli otworzyć trzeci terminal (patrz obrazek poniżej) -
Teraz użyjmy flagi -C w trzecim terminalu -
$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 0.051 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 1968.12 [#/sec] (mean)
Time per request: 5.081 [ms] (mean)
Time per request: 0.508 [ms] (mean, across all concurrent requests)
Transfer rate: 532.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.9 2 4
Processing: 0 3 0.9 3 5
Waiting: 0 2 1.1 2 4
Total: 4 5 0.7 5 7
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 5
80% 6
90% 6
95% 6
98% 7
99% 7
100% 7 (longest request)Z powyższego wyniku zauważamy kilka punktów. Po pierwsze, web2py używa serwera WWW Rocket . Zauważamy również, że otrzymujemy „odpowiedzi inne niż 2xx” oprócz wcześniej omówionych nagłówków w wynikach. Ogólnie protokół Http odpowiada na żądanie za pomocą kodu odpowiedzi, a wszystko w zakresie 200s oznacza „w porządku”, a reszta odpowiada jakiemuś problemowi. Na przykład 400s to błędy związane z zasobami, takie jak 404 File Not Found. 500 odpowiada błędom serwera. W naszym natychmiastowym przypadku nie ma żadnego błędu, z wyjątkiem sytuacji, gdy używamy opcji -C. Można to wyłączyć za pomocą opcji -l, jak już opisano.
Sprawdzanie strony administratora
W tej sekcji zrozumiemy, jak sprawdzić stronę administratora. Dla porównania przetestujmy inny adres URL aplikacji web2py -
$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/adminWynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /admin
Document Length: 8840 bytes
Concurrency Level: 10
Time taken for tests: 2.077 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 926700 bytes
HTML transferred: 884000 bytes
Requests per second: 48.14 [#/sec] (mean)
Time per request: 207.749 [ms] (mean)
Time per request: 20.775 [ms] (mean, across all concurrent requests)
Transfer rate: 435.61 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 12
Processing: 62 204 52.2 199 400
Waiting: 61 203 52.0 199 400
Total: 62 205 54.3 199 411
Percentage of the requests served within a certain time (ms)
50% 199
66% 211
75% 220
80% 226
90% 264
95% 349
98% 381
99% 411
100% 411 (longest request)W szczególności należy zwrócić uwagę na odpowiednie statystyki w sekcji „Czas połączeń” i „Procent obsłużonych żądań…” w http://127.0.0.1:8000/ i http://127.0.0.1:8000/admin. Istnieje ogromna różnica.
Korzystanie z opcji Timelimit
Ogólnie rzecz biorąc, opcja Timelimit jest trudna. Rozumiemy to z podręcznika ab , który jest dość wyjaśniający -
-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.Przeprowadźmy test z tą opcją. Zanotujemy nasze obserwacje po przejściu przez wyjście -
$ ab -n 100 -c 10 -t 60 http://127.0.0.1:8000/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 22.547 seconds
Complete requests: 50000
Failed requests: 0
Non-2xx responses: 50000
Total transferred: 13850000 bytes
HTML transferred: 3300000 bytes
Requests per second: 2217.61 [#/sec] (mean)
Time per request: 4.509 [ms] (mean)
Time per request: 0.451 [ms] (mean, across all concurrent requests)
Transfer rate: 599.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.8 2 8
Processing: 0 2 3.2 2 218
Waiting: 0 2 3.2 2 218
Total: 2 4 3.1 4 220
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 5
90% 5
95% 5
98% 7
99% 8
100% 220 (longest request)Zwróć uwagę, że dane wyjściowe pokazują, że ta opcja zastępuje liczbę żądań określoną przez -nopcja i kontynuuje do 50 tys. żądań. Jednakże, ponieważ żądania zostały obsłużone bardzo szybko, ab wygasło po osiągnięciu poziomu 50 tys. - w ciągu 22 sekund (patrz nagłówek Czas potrzebny na testy) w tym przypadku.
Możesz przetestować zastępowanie tego samego polecenia http://127.0.0.1:8000/ z http://127.0.0.1:8000/admin (zakładając, że jest to nasza aplikacja web2py) lub strona trzecia, taka jak https://www.apache.org/, zauważ różnicę w statystykach.
Lista kontrolna przed wykonaniem testu obciążenia
Istnieje kilka testów, które pomogą Ci pomyślnie przeprowadzić test i dokładnie zmierzyć jego wydajność. Przed wykonaniem testu obciążenia weź pod uwagę następujące warunki:
Upewnij się, że żaden dodatkowy moduł Pythona nie jest załadowany.
Aby uniknąć wyczerpania portu TCP / IP, należy zazwyczaj odczekać 2-3 minuty przed przejściem do kolejnego testu ab.
Upewnij się, że liczba jednoczesnych połączeń jest niższa niż liczba wątków roboczych Apache.
Powinieneś ponownie uruchomić serwer przed wykonaniem kolejnego testu, jeśli Apache lub Python ulegnie awarii.
W tym rozdziale opiszemy różne kombinacje -n i -c z ważnymi flagami, aby stopniowo zwiększać obciążenie serwera internetowego.
Skoncentruj się głównie na tym, jak następujące wskaźniki zmieniają się w miarę zwiększania obciążenia -
- Żądania na sekundę
- Czas połączenia (ms)
- Procent żądań obsłużonych w określonym czasie (ms)
Należy również zwrócić uwagę na wartość progową, gdy serwer zaczyna się blokować i zaczynasz otrzymywać nieudane żądania.
1 Jednoczesny użytkownik wykonujący 100 odsłon
Wykonajmy 100 kolejnych wczytywania stron przez jednego użytkownika -
$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 1
Time taken for tests: 0.045 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2206.24 [#/sec] (mean)
Time per request: 0.453 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 596.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.0 0 1
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 1
95% 1
98% 1
99% 1
100% 1 (longest request)5 jednoczesnych użytkowników wykonujących 10 odsłon
Ten przypadek odpowiada szczytowemu obciążeniu witryny internetowej, które odnotowuje ponad 50 000 odwiedzin miesięcznie.
$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/W kolejnych wynikach pominiemy wspólny nagłówek dla zachowania przejrzystości.
Wynik
...
Requests per second: 2009.24 [#/sec] (mean)
Time per request: 2.488 [ms] (mean)
Time per request: 0.498 [ms] (mean, across all concurrent requests)
Transfer rate: 543.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 2
Processing: 0 1 0.5 1 2
Waiting: 0 1 0.5 1 1
Total: 2 2 0.4 3 3
ERROR: The median and mean for the total time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 3
99% 3
100% 3 (longest request)10 jednoczesnych użytkowników wykonujących 10 odsłon
Ten test odpowiada 100 ładowaniom stron przez 10 różnych jednoczesnych użytkowników, z których każdy wykonuje 10 kolejnych ładowań stron.
$ ab -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Wynik
...
Requests per second: 2225.68 [#/sec] (mean)
Time per request: 4.493 [ms] (mean)
Time per request: 0.449 [ms] (mean, across all concurrent requests)
Transfer rate: 602.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 1.0 2 3
Waiting: 0 1 1.0 2 3
Total: 4 4 0.3 4 4
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 4 (longest request)20 jednoczesnych użytkowników wykonujących 20 odsłon
Ten test odpowiada 400 ładowaniom stron przez 20 różnych jednoczesnych użytkowników, z których każdy wykonuje 20 kolejnych ładowań stron.
$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/Wynik
...
Requests per second: 1619.96 [#/sec] (mean)
Time per request: 12.346 [ms] (mean)
Time per request: 0.617 [ms] (mean, across all concurrent requests)
Transfer rate: 438.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.3 6 10
Processing: 1 5 2.9 5 10
Waiting: 0 5 2.9 5 9
Total: 10 11 0.6 11 12
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 12
95% 12
98% 12
99% 12
100% 12 (longest request)30 jednoczesnych użytkowników wykonujących 30 odsłon
Ten test odpowiada 900 załadowaniom stron przez 30 różnych jednoczesnych użytkowników, każdy użytkownik wykonuje 30 kolejnych ładowań stron.
$ ab -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Wynik
...
Requests per second: 2283.45 [#/sec] (mean)
Time per request: 13.138 [ms] (mean)
Time per request: 0.438 [ms] (mean, across all concurrent requests)
Transfer rate: 617.69 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.7 6 11
Processing: 1 6 3.1 6 11
Waiting: 0 5 3.2 5 10
Total: 11 12 0.5 12 13
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 13
95% 13
98% 13
99% 13
100% 13 (longest request)Dowiedzieliśmy się teraz, jak stopniowo zwiększać obciążenie witryny i testować jej wydajność.
W tym rozdziale porównamy wyniki z flagami i bez. Zobaczmy, jak użycie odpowiednich flag może zwiększyć wydajność Twojej aplikacji internetowej. Wcześniej musimy zrozumieć, że jeśli Twoja aplikacja jest prosta, możesz nie zauważyć różnicy. Tak jak w przypadku naszej prostej aplikacji, z flagami i bez flag. Następnie wykonamy ten sam test zhttps://www.apache.org/ URL i zobacz różnicę.
Testowanie naszej aplikacji bez flag
W tej sekcji dowiemy się, jak przetestować naszą aplikację bez flag.
$ ab -n 100 -c 10 http://127.0.0.1:8000/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.244 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2208.77 [#/sec] (mean)
Time per request: 4.527 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 597.49 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.3 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 5
80% 5
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Testowanie naszej aplikacji z flagami
W tej sekcji dowiemy się, jak przetestować naszą aplikację z flagami.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/Wynik
...
Requests per second: 2277.07 [#/sec] (mean)
Time per request: 4.392 [ms] (mean)
Time per request: 0.439 [ms] (mean, across all concurrent requests)
Transfer rate: 615.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.2 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)Możemy po prostu zauważyć, że nie ma dużej różnicy między statystykami wyjściowymi.
Testowanie witryny organizacji Apache bez flag
Zobaczmy teraz, jak przetestować witrynę internetową organizacji Apache bez flag.
$ ab -n 100 -c 10 http://www.apache.org/Wynik
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 80
Document Path: /
Document Length: 58433 bytes
Concurrency Level: 10
Time taken for tests: 1.498 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5877500 bytes
HTML transferred: 5843300 bytes
Requests per second: 66.74 [#/sec] (mean)
Time per request: 149.840 [ms] (mean)
Time per request: 14.984 [ms] (mean, across all concurrent requests)
Transfer rate: 3830.58 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 110 295.2 12 1012
Processing: 37 38 0.5 38 39
Waiting: 12 13 0.3 13 15
Total: 49 147 295.4 50 1051
Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 816
95% 1050
98% 1051
99% 1051
100% 1051 (longest request)Testowanie witryny organizacji Apache z flagami
Przetestujmy teraz witrynę organizacji Apache z flagami.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.apache.org/Wynik
...
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.357 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 1358510 bytes
HTML transferred: 1317700 bytes
Requests per second: 280.28 [#/sec] (mean)
Time per request: 35.678 [ms] (mean)
Time per request: 3.568 [ms] (mean, across all concurrent requests)
Transfer rate: 3718.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.7 0 12
Processing: 14 17 21.3 15 227
Waiting: 14 17 21.3 14 227
Total: 14 18 21.5 15 227
Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 27
95% 28
98% 29
99% 227
100% 227 (longest request)Możesz po prostu zauważyć, jak żądanie na sekundę wzrosło dzięki użyciu flag. W tym przypadku jest to szczególnie spowodowane użyciem-H "Accept-Encoding: gzip, deflate, ponieważ ta flaga informuje serwer Apache, aby obsługiwał żądania w formacie gzipped format.
Biorąc pod uwagę wyniki Apache Bench
Jeśli chodzi o wyniki Apache Bench, należy wziąć pod uwagę kilka ważnych punktów. Pomoże nam to zaprojektować naszą ogólną strategię usuwania wąskich gardeł w naszej aplikacji i poprawiać jej wydajność.
Musimy żądać na sekundę. To daje nam wyobrażenie o tym, jak dobrze działa konfiguracja naszego serwera internetowego; im większa liczba, tym lepsza wydajność. Następnie przychodzi czas połączenia (ms) i procent obsługiwanych żądań. Może być konieczne dostosowanie ustawień serwera internetowego, aby zmienić te wskaźniki na żądaną wydajność.
Sprawdź, czy nie ma błędów w dziennikach błędów Apache lub używanego serwera WWW lub dziennikach (ogólnych). W miarę zwiększania obciążenia rzeczy zaczną się dławić: zaczną pojawiać się problemy z pamięcią. Wiele skryptów Pythona zacznie się zawieszać, jeśli nie zostaną napisane z myślą o współbieżności.
Musisz dowiedzieć się, jaka jest krytyczna wartość współbieżności, powyżej której Twój serwer sieciowy ulega awarii i / lub przekracza limit czasu? Zwykle powinno to mieć miejsce na dość wysokim poziomie współbieżności. Jeśli ta wartość jest niska, coś jest nie tak i musisz zmienić te ustawienia na niższe / wyższe.
Wniosek
W tym samouczku dowiedzieliśmy się, jak można użyć Apache Bench do testowania ładowania dowolnej witryny internetowej lub aplikacji internetowej. Apache Bench może być bardzo cennym narzędziem do określania, w jaki sposób należy ulepszyć konfigurację serwera aplikacji internetowych, aby zmniejszyć wąskie gardła i zwiększyć wydajność. Teraz, gdy znasz już podstawowe użycie Apache Bench, możesz zacząć od stworzenia nowych planów testów, aby zmierzyć wydajność aplikacji w różnych scenariuszach.