У меня есть сайт в PHP, Lighttpd. Он также использует MySQL на Centos 5. Я протестировал свой PHP с кодом ниже с Apache Bench (ab). Это привело к некоторым ошибкам (Failed Requests), указывающим другую длину, чем обычно. Я абсолютно уверен, что мой 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) Запустите 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 для просмотра заголовков ответов на один запрос с сжатием и без него.
Использовать tcpdump
Откройте qty 2 терминала / окна оболочки или просто используйте экран.
В первом окне используйте tcpdump для захвата данных передачи из / в вашу NIC (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"
Вы должны иметь возможность контролировать все сегменты данных оттуда путем поиска или получения результатов.
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 будет терпеть неудачу с ошибкой Length, так как выход будет одним символом дольше.