Неудачные запросы по длине в моем тестовом результате загрузки ApacheBench

Question

У меня есть сайт в PHP, Lighttpd. Он также использует MySQL на Centos 5. Я протестировал свой PHP с кодом ниже с Apache Bench (ab). Это привело к некоторым ошибкам (Failed Requests), указывающим другую длину, чем обычно. Я абсолютно уверен, что мой PHP-результат должен всегда иметь одинаковую точную длину. Я просмотрел журналы журналов Lighttpd и MySQL и журналы ошибок и там не было никаких ошибок.

Есть ли способ проверить, что именно происходит, когда результат имеет другую длину или есть ли другой способ узнать, в чем причина или что такое «плохой» результат?

Мне нужно знать, потому что мне нужно иметь 100% хорошие результаты.

-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) 

Answer 1

Запустите ab с параметром -v 2, что означает уровень детализации 2. Это приведет к сбросу заголовков ответов. Если ваши запросы не используют закодированную кодировку, вы увидите заголовок «Content-Length», указывающий размер каждого ответа.

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

... 

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

Если ваши ответы используют закодированное кодирование, длина неизвестна до тех пор, пока передача не закончится. Обычно закодированное кодирование используется только для сжатых ответов, и ApacheBench не выполняет сжатие по умолчанию.

Если - сжимает ответы по любой причине, которые могли бы объяснить это; сжатая длина зависит от содержимого.

Вы также можете использовать curl -i и опцию --compress, чтобы видеть заголовки ответов на один запрос с сжатием и без него.

Answer 2

Использование Tcpdump

Открыть Кол окна 2 терминала/оболочки или просто использовать экран.

В первом окне, использование ТСРйитра для сбора данных передачи от/до вашего NIC (eth0) в файл:

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

Во втором окне выпалить вашу команду аб:

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

Когда это все сделано, разобрать файл со строками и Grep:

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

Вы должны быть в состоянии Monito r все сегменты данных оттуда путем поиска или получения результатов.

Answer 3

ab предполагает, что все ответы одинаковы. Он рассматривает длину содержимого первого ответа, а затем сравнивает другие с этим.

От человека странице:

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. 

Так что, если ваш первый запрос содержит следующие данные:

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

и следующий является:

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

аб потерпит неудачу с Ошибка длины, так как выход один символ длиннее.