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

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

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

Мне нужно это знать, потому что мне нужны 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)

php scalability load-testing apachebench lighttpd
person Tomasz Smykowski    schedule 02.10.2009    source источник

Ответы (3)


arrow_upward
19
arrow_downward

Запустите 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, чтобы увидеть заголовки ответа на один запрос со сжатием и без него.

person Tim Sylvester    schedule 03.07.2010
comment
Комментарий анонимного пользователя (редактирование отклонено): Примечание. ab ожидает, что все ответы будут одинакового размера. Если есть вероятность того, что ваши выходные данные будут различаться по размеру, вам следует игнорировать Неудачные запросы, так как ab будет считать их неудачными. - person Anne; 13.12.2011

arrow_upward
4
arrow_downward

Использовать tcpdump

Откройте кол-во 2 окна терминала/оболочки или просто используйте screen.

В первом окне используйте tcpdump для захвата данных передачи с/на вашу сетевую карту (eth0) в файл:

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

Во втором окне запустите команду ab:

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

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

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

Вы должны иметь возможность отслеживать все сегменты данных оттуда, просматривая результаты на глаз или с помощью grep'а.

person randomx    schedule 03.10.2009
comment
Я получаю сообщение «tcpdump: ioctl: нет такого устройства» при попытке sudo tcpdump - person Tomasz Smykowski; 03.10.2009
comment
Я сделал то, что вы написали, и вот результаты: -- ‹/noscript› ‹!-- End Quantcast tag --› HTTP/1.0 200 OK Connection: close X-Powered-By: PHP/5.2.6 Content-type: text /html Как мне интерпретировать этот результат? - person Tomasz Smykowski; 03.10.2009
comment
Tomaszs: вам придется изменить идентификатор устройства NIC для любой операционной системы *nix, на которой вы работаете. en0 на Mac, eth0 на Linux и т. д. HTTP/1.0 200 OK означает, что веб-сервер нашел запрошенный ресурс и вернул содержимое. Страница прошла успешно! Вам просто нужно будет прочитать содержимое myfile2.txt, чтобы увидеть, где появляются ошибки. - person randomx; 07.10.2009
comment
Что именно делает команда strings? В чем разница между напрямую grep из каталога файла? - person cedricliang; 11.01.2016

arrow_upward
2
arrow_downward

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"}

ab завершится с ошибкой длины, так как вывод будет на один символ длиннее.

person Tom    schedule 29.06.2016