Неудавшиеся запросы длиной в моем результате нагрузочного теста ApacheBench
Слово предупреждения: если вы поместите файлы конфигурации в папку WEB-INF/classes, а ваша среда IDE, скажем, Eclipse, выполняет очистку / перестройку, она будет уничтожать ваши файлы conf, если они не были в исходном каталоге Java. Большой ответ BalusC намекает на то, что в варианте 1, но я хотел добавить акцент.
Я усвоил, что если вы «скопируете» веб-проект в Eclipse, он очистит / перестроит из любых исходных папок , В моем случае я добавил «связанный исходный каталог» из нашей Java-библиотеки POJO, он будет скомпилирован в папку WEB-INF/classes. Выполнение чистых / перестроек в этом проекте (а не в проекте веб-приложений) вызвало ту же проблему.
Я думал о том, чтобы поместить мои confs в папку POJO src, но эти confs - все для сторонних библиотек (например, Quartz или URLRewrite), которые находятся в папке WEB-INF/lib, так что это не имеет смысла , Я планирую протестировать его размещение в папке «src» веб-проектов, когда я обхожусь к нему, но эта папка в настоящее время пуста, и в ней есть файлы conf, которые выглядят inelegant.
Итак, я голосую за то, в WEB-INF/commonConfFolder/filename.properties, next в папку классов, которая является параметром Balus 2.
2 ответа
Выполните 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
Откройте кол-во 2 окон терминала / оболочки или просто используйте экран.
В первом окне используйте 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"
Вы сможете отслеживать все сегменты данных оттуда, просматривая или просматривая результаты.