Czy ktoś może przeprowadzić mnie przez proces testowania mojej witryny przy użyciu narzędzia Apache Bench Tool ( ab)?
Chcę wiedzieć, co następuje:
Ile osób na minutę może obsługiwać witryna?
Przeprowadź mnie przez polecenia, które powinienem uruchomić, aby to rozgryźć.
Próbowałem każdego tutoriala i są mylące.
Odpowiedzi:
Narzędzie testu porównawczego apache jest bardzo proste i chociaż daje solidne wyobrażenie o pewnej wydajności, złym pomysłem jest poleganie tylko na nim, jeśli planujesz wystawić witrynę na poważne obciążenie produkcyjne.
Powiedziawszy to, oto najczęstsze i najprostsze parametry:
-c: ("Konkurencja"). Wskazuje, ilu klientów (osób / użytkowników) będzie odwiedzało witrynę w tym samym czasie. Podczas aburuchomień będą -cpojawiać się klienci odwiedzający witrynę. To właśnie decyduje o poziomie stresu, jaki Twoja witryna będzie odczuwać podczas testu porównawczego.
-n: Wskazuje, ile żądań zostanie złożonych. To decyduje tylko o długości testu. Wysoka -nwartość z -cwartością, którą może obsługiwać Twój serwer, jest dobrym pomysłem, aby upewnić się, że nie dojdzie do załamania pod wpływem długotrwałego stresu: wsparcie stresu przez 5 sekund niż przez 5 godzin nie jest tym samym.
-k: Robi to przeglądarka funkcjonalna „KeepAlive” z natury. Nie musisz przekazywać wartości, -kponieważ jest ona „logiczna” (co oznacza: oznacza, że chcesz, aby Twój test używał nagłówka Keep Alive z HTTP i podtrzymywał połączenie). Ponieważ przeglądarki to robią i prawdopodobnie zechcesz symulować obciążenie i przepływ witryny z przeglądarek, zaleca się wykonanie testu porównawczego.
Ostatnim argumentem jest po prostu host. Domyślnie trafi protokół http: //, jeśli go nie określisz.
ab -k -c 350 -n 20000 example.com/
Wydając powyższe polecenie, uderzysz http://example.com/ z 350 jednoczesnymi połączeniami, aż do spełnienia 20 tysięcy żądań. Zostanie to zrobione za pomocą nagłówka Keep Alive.
Po zakończeniu procesu 20 tysięcy zapytań otrzymasz informację zwrotną na temat statystyk. Dzięki temu dowiesz się, jak dobrze działała strona pod obciążeniem, jakie stawiasz, gdy używasz powyższych parametrów.
Aby dowiedzieć się, ile osób witryna może obsłużyć w tym samym czasie, po prostu sprawdź, czy czasy odpowiedzi (średnie, minimalne i maksymalne czasy odpowiedzi, nieudane żądania itp.) To liczby, które witryna może zaakceptować (różne witryny mogą chcieć różnych prędkości). Możesz uruchomić narzędzie z różnymi wartościami -c, dopóki nie trafisz w miejsce, w którym powiesz „Jeśli go zwiększę, zaczyna otrzymywać nieudane żądania i pęka”.
W zależności od witryny oczekujesz średniej liczby żądań na minutę. Różni się tak bardzo, że nie będziesz w stanie tego symulować za pomocą ab. Pomyśl jednak o tym w ten sposób: jeśli przeciętny użytkownik będzie uderzał 5 żądań na minutę, a średni czas odpowiedzi, który uważasz za prawidłowy, wynosi 2 sekundy, oznacza to, że 10 sekund na minutę 1 użytkownik będzie na żądanie, co oznacza tylko 1/6 czasu trafi na stronę. Oznacza to również, że jeśli 6 użytkowników jednocześnie odwiedza witrynę za pomocą ab, prawdopodobnie będziesz mieć 36 użytkowników w symulacji, nawet jeśli poziom współbieżności (-c) wynosi tylko 6.
Zależy to od zachowania, jakiego oczekujesz od użytkowników korzystających z witryny, ale możesz je uzyskać z „Oczekuję, że mój użytkownik trafi X żądań na minutę i uważam, że średni czas odpowiedzi jest ważny, jeśli wynosi 2 sekundy”. Następnie po prostu zmodyfikuj swój poziom -c, aż osiągniesz 2 sekundy średniego czasu odpowiedzi (ale upewnij się, że maksymalny czas odpowiedzi i stddev są nadal ważne) i sprawdź, jak duży możesz zrobić -c.
Mam nadzieję, że wyjaśniłem to jasno :) Powodzenia
-lopcję, jeśli strona ma zawartość dynamiczną, w ten sposób nie otrzymujesz wielu nieudanych żądań, ponieważ długość treści różni się między żądaniami.
Przeprowadź mnie przez polecenia, które powinienem uruchomić, aby to rozgryźć.
Najprostszym testem, jaki możesz wykonać, jest wykonanie 1000 żądań, po 10 naraz (co w przybliżeniu symuluje 10 równoczesnych użytkowników, którzy otrzymują po 100 stron - przez cały czas trwania testu).
ab -n 1000 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.example.com/
-n 1000 to liczba żądań do złożenia.
-c 10 mówi AB, aby wykonywał 10 żądań na raz, zamiast 1 na raz, aby lepiej symulować równoczesnych gości (w porównaniu z użytkownikami sekwencyjnymi).
-kwysyła KeepAlivenagłówek, który prosi serwer WWW, aby nie zamykał połączenia po wykonaniu każdego żądania, ale zamiast tego używał go ponownie.
Wysyłam również dodatkowy nagłówek, Accept-Encoding: gzip, deflateponieważ mod_deflate jest prawie zawsze używany do kompresji danych wyjściowych text / html 25% -75% - których efektów nie należy odrzucać ze względu na jego wpływ na ogólną wydajność serwera WWW (tj. może przesłać 2x dane w tym samym czasie itp.).
Wyniki:
Benchmarking www.example.com (be patient)
Completed 100 requests
...
Finished 1000 requests
Server Software: Apache/2.4.10
Server Hostname: www.example.com
Server Port: 80
Document Path: /
Document Length: 428 bytes
Concurrency Level: 10
Time taken for tests: 1.420 seconds
Complete requests: 1000
Failed requests: 0
Keep-Alive requests: 995
Total transferred: 723778 bytes
HTML transferred: 428000 bytes
Requests per second: 704.23 [#/sec] (mean)
Time per request: 14.200 [ms] (mean)
Time per request: 1.420 [ms] (mean, across all concurrent requests)
Transfer rate: 497.76 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 5 14 7.5 12 77
Waiting: 5 14 7.5 12 77
Total: 5 14 7.5 12 77
Percentage of the requests served within a certain time (ms)
50% 12
66% 14
75% 15
80% 16
90% 24
95% 29
98% 36
99% 41
100% 77 (longest request)
Dla najprostszej interpretacji zignoruj wszystko, ALE ta linia:
Requests per second: 704.23 [#/sec] (mean)
Pomnóż to przez 60, a otrzymasz swoje żądania na minutę.
Aby uzyskać rzeczywiste wyniki, musisz przetestować Wordpress zamiast jakiegoś statycznego pliku HTML lub index.php, ponieważ musisz wiedzieć, jak wszystko działa razem: w tym złożony kod PHP i wiele zapytań MySQL ...
Na przykład tutaj są wyniki testowania nowej instalacji Wordpressa w tym samym systemie i środowisku WAMP (używam WampDeveloper, ale są też Xampp, WampServer i inne) ...
Requests per second: 18.68 [#/sec] (mean)
To teraz 37x wolniej!
Po teście obciążenia można wykonać wiele czynności, aby poprawić ogólną wydajność (liczba żądań na sekundę), a także zwiększyć stabilność serwera WWW przy większym obciążeniu (np. Zwiększenie -ni -ctendencja do awarii Apache), które: możesz przeczytać tutaj:
Kroki konfigurowania Apache Bench (AB) w systemie Windows (IMO - zalecane).
Krok 1 - Zainstaluj Xampp.
Krok 2 - Otwórz CMD.
Krok 3 - Przejdź do miejsca docelowego stanowiska apache ( cd C:\xampp\apache\bin) z CMD
Krok 4 - Wklej polecenie ( ab -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://localhost:yourport/)
Krok 5 - Zaczekaj na to. Jesteś skończony
Byłem również ciekawy, czy mogę zmierzyć szybkość mojego skryptu za pomocą apache abs, skryptu konstrukcyjnego / destrukcyjnego php lub rozszerzenia php.
dwa ostatnie zawiodły dla mnie: są przybliżone. po czym pomyślałem o wypróbowaniu „ab” i „abs”.
polecenie „ab -k -c 350 -n 20000 example.com/” jest piękne, ponieważ wszystko jest łatwiejsze!
ale czy ktoś pomyślał o „localhost” na dowolnym serwerze Apache, na przykład www.apachefriends.org?
powinieneś utworzyć folder taki jak „bench” w katalogu głównym, w którym masz 2 pliki: przetestuj „bench.php” i odwołaj się do „void.php”.
<?php
for($i=1;$i<50000;$i++){
print ('qwertyuiopasdfghjklzxcvbnm1234567890');
}
?>
<?php
?>
"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
pause
Teraz, jeśli uważnie zwrócisz uwagę ...
skrypt void nie daje zerowych wyników !!! WNIOSEK JEST: od drugiego wyniku pierwszy wynik powinien zostać zmniejszony !!!
tutaj mam:
c:\xampp\htdocs\bench>"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/void.php
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/void.php
Document Length: 0 bytes
Concurrency Level: 1
Time taken for tests: 11.219 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 2150000 bytes
HTML transferred: 0 bytes
Requests per second: 891.34 [#/sec] (mean)
Time per request: 1.122 [ms] (mean)
Time per request: 1.122 [ms] (mean, across all concurrent requests)
Transfer rate: 187.15 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 0 1 0.9 1 17
Waiting: 0 1 0.9 1 17
Total: 0 1 0.9 1 17
Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 2
98% 2
99% 3
100% 17 (longest request)
c:\xampp\htdocs\bench>"c:\xampp\apache\bin\abs.exe" -n 10000 http://localhost/bench/bench.php
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: Apache/2.4.33
Server Hostname: localhost
Server Port: 80
Document Path: /bench/bench.php
Document Length: 1799964 bytes
Concurrency Level: 1
Time taken for tests: 177.006 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 18001600000 bytes
HTML transferred: 17999640000 bytes
Requests per second: 56.50 [#/sec] (mean)
Time per request: 17.701 [ms] (mean)
Time per request: 17.701 [ms] (mean, across all concurrent requests)
Transfer rate: 99317.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 12 17 3.2 17 90
Waiting: 0 1 1.1 1 26
Total: 13 18 3.2 18 90
Percentage of the requests served within a certain time (ms)
50% 18
66% 19
75% 19
80% 20
90% 21
95% 22
98% 23
99% 26
100% 90 (longest request)
c:\xampp\htdocs\bench>pause
Press any key to continue . . .
90-17 = 73 wynik, którego oczekuję!
Testowanie interfejsu API przy użyciu samego ab nie wystarczy. Uważam jednak, że jest to świetne narzędzie, które daje podstawowe wyobrażenie o wydajności witryny.
Jeśli chcesz użyć polecenia ab w celu przetestowania wielu punktów końcowych interfejsu API z różnymi danymi w tym samym czasie w tle, musisz użyć polecenia „nohup”. Uruchamia dowolne polecenie nawet po zamknięciu terminalu.
Napisałem prosty skrypt, który automatyzuje cały proces, możesz go użyć: http://blog.ikvasnica.com/entry/load-test-multiple-api-endpoints-concurrently-use-this-simple-shell-script