Nieudane żądania według długości w moim wyniku testu obciążenia ApacheBench

Mam stronę internetową w PHP, Lighttpd. Używa również MySQL na Centos 5. Przetestowałem mój PHP z kodem poniżej z Apache Bench (ab). Spowodowało to pewne błędy (Żądania Nieudane) wskazujące inną długość niż normalnie. Jestem absolutnie pewien, że mój wynik PHP powinien zawsze mieć dokładnie taką samą długość. Sprawdziłem dzienniki i dzienniki błędów Lighttpd i MySQL i nie mam tam żadnych błędów.Nieudane żądania według długości w moim wyniku testu obciążenia ApacheBench

Czy istnieje sposób, aby dokładnie sprawdzić, co ma ab, gdy wynik ma inną długość lub czy istnieje inny sposób, aby dowiedzieć się, jaka jest przyczyna lub jaki jest "zły" wynik?

Muszę to wiedzieć, ponieważ muszę mieć 100% dobrych wyników.

-bash-3.2# ab -n 500 -c 200 http://domain.com/test/index.php 
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Copyright 2006 The Apache Software Foundation, http://www.apache.org/ 

Benchmarking domain.com (be patient) 
Completed 100 requests 
Completed 200 requests 
Completed 300 requests 
Completed 400 requests 
Finished 500 requests 


Server Software:  lighttpd/1.4.20 
Server Hostname:  domain.com 
Server Port:   80 

Document Path:   /test/index.php 
Document Length:  15673 bytes 

Concurrency Level:  200 
Time taken for tests: 0.375862 seconds 
Complete requests:  500 
Failed requests:  499 
    (Connect: 0, Length: 499, Exceptions: 0) 
Write errors:   0 
Total transferred:  7920671 bytes 
HTML transferred:  7837000 bytes 
Requests per second: 1330.28 [#/sec] (mean) 
Time per request:  150.345 [ms] (mean) 
Time per request:  0.752 [ms] (mean, across all concurrent requests) 
Transfer rate:   20579.36 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 10 9.4  6  30 
Processing:  0 113 133.5  16  342 
Waiting:  0 111 134.3  12  341 
Total:   0 123 138.9  16  370 

Percentage of the requests served within a certain time (ms) 
    50%  16 
    66% 235 
    75% 289 
    80% 298 
    90% 331 
    95% 345 
    98% 365 
    99% 368 
100% 370 (longest request)

Źródło

2009-10-02 Tomasz Smykowski

Uruchom ab z parametrem -v 2, co oznacza poziom szczegółowości 2. Spowoduje to zrzuty nagłówków odpowiedzi. Jeśli twoje żądania nie używają kodowania kodowanego, zobaczysz nagłówek "Długość treści", wskazujący rozmiar każdej odpowiedzi.

gw:~$ ab -n 1 -v 2 "http://whatever.com/" 

... 

LOG: header received: 
HTTP/1.0 200 OK 
... 
Content-Length: 1568399

Jeśli reakcje przy użyciu kodowania pakietowego, wtedy długość nie jest to wiadome dopóki przeniesienie końca. Zwykle kodowanie klockowe jest używane tylko w przypadku skompresowanych odpowiedzi, a ApacheBench domyślnie nie kompresuje.

Jeśli to jest kompresowanie odpowiedzi z jakiegokolwiek powodu, który mógłby wyjaśnić; skompresowana długość zależy od zawartości.

Można również użyć opcji curl -i i, aby wyświetlić nagłówki odpowiedzi dla pojedynczego żądania z kompresją i bez niej.

Źródło

2010-07-03 01:11:09

+27

** Komentarz użytkownika anonimowego (odrzucona edycja): ** Uwaga: 'ab' oczekuje, że wszystkie odpowiedzi będą miały równy rozmiar. Jeśli jest jakakolwiek szansa, że Twój wynik będzie różnił się wielkością, powinieneś zignorować "Żądania nieudane", ponieważ "ab" uzna je za nieudane. – Anne

Zastosowanie tcpdump

Otwarte il okna Terminal 2/powłoki lub po prostu korzystać z ekranu.

W pierwszym oknie, korzystanie tcpdump do przechwytywania danych transmisyjnych z/do karty sieciowej (eth0) do pliku:

sudo tcpdump -s 9999 -i eth0 -w myfile.txt

w drugim oknie, wystrzelić swoją komendę AB:

ab -n 500 -c 200 http://domain.com/test/index.php

Kiedy to wszystko zrobić, analizować plik z łańcuchów i grep:

strings myfile2.txt | grep -C 3 "200 OK"

powinny mieć możliwość monito r wszystkie segmenty danych stamtąd przez gałki oczne lub grep'ing wyniki.

Źródło

2009-10-03 00:12:46

I get 'tcpdump: ioctl: Nie ma takiego urządzenia' komunikat podczas próby sudo tcpdump –

Zrobiłem to, co napisałeś, a to są wyniki: - HTTP/1.0 200 OK Połączenie: zamknij Zasilanie przez X: PHP/5.2.6 Typ zawartości: tekst/html Jak powinienem interpretować ten wynik? –

Tomaszs: będziesz musiał zmienić identyfikator urządzenia NIC dla dowolnego systemu operacyjnego * nix, z którego korzystasz. en0 na Macu, eth0 na Linuxie, itp. HTTP/1.0 200 OK oznacza, że serwer WWW odnalazł żądany zasób i zwrócił treść. Strona powiodła się! Wystarczy, że przeczytasz zawartość pliku myfile2.txt, aby zobaczyć, gdzie pojawiają się awarie. –

ab zakłada, że wszystkie odpowiedzi są takie same. Sprawdza długość treści pierwszej odpowiedzi, a następnie porównuje inne.

Od strony man:

Document Length 
    This is the size in bytes of the first successfully returned document. 
    If the document length changes during testing, the response is 
    considered an error.

Więc jeśli pierwszy wniosek zawiera następujące dane:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.3"}

a kolejna jest:

{"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.30"}

ab nie powiedzie się z Błąd długości, ponieważ wynik jest dłuższy o jeden znak.

Źródło

2016-06-29 11:57:30 Tom

Nieudane żądania według długości w moim wyniku testu obciążenia ApacheBench

Odpowiedz

Powiązane problemy