Назад | Перейти на главную страницу

Неудачные запросы AB. Что я могу с ними поделать?

Итак, в прошлом у меня никогда не было проблем с этим приложением. Все тесты имели 100% успех. Вчера я настроил nginx на сервер статического контента и передал другие запросы apache. Теперь, если у меня есть 1 одновременный пользователь (-c 1), все в порядке. Но кажется, что чем больше у меня одновременных пользователей, тем больше неудавшихся запросов я получаю. Немного, но, может быть, около 10 или 15 из 350. Они «длинные», что бы это ни значило. Посещая сайт в браузере, у меня вообще нет никаких проблем. Как я могу узнать причину неудачных запросов?

Вот часть моего httpd.conf:

Timeout 20

KeepAlive Off

MaxKeepAliveRequests 100

<IfModule prefork.c>
StartServers 1
MinSpareServers 1
MaxSpareServers 3
ServerLimit 50
MaxClients 50
MaxRequestsPerChild  4000
</IfModule>

<IfModule worker.c>
StartServers 1
MaxClients 50
MinSpareThreads     25
MaxSpareThreads     75 
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>

Вам нужна другая информация?

Эти сбои "длины" просто означают, что длина содержимого (объем данных, обслуживаемых вашим приложением) для некоторых попыток не совпадала с длиной первого запроса. Итак, если ab получил 100 байт в первый раз. а затем получил 150 байтов следующие 9 раз, он сообщит об ошибке длины 9.

Если вы обслуживаете динамический контент, эти ошибки ожидаемы, и их можно безопасно игнорировать.

Ответ Марко Рамоса неверен, нет причин делать что-то вроде запуска netstat.

Вот лучшее объяснение от кого-то из Stackoverflow:

Нагрузочное тестирование с AB… поддельные неудачные запросы (длина)

Я предполагаю, что вы достигаете предела MaxClients, когда тестируете сайт.

При тестировании сайта попробуйте увидеть, сколько подключений установлено через порт 80:

netstat -tnap | grep ":80" | grep -c ESTA

Повторите эту команду несколько раз при тестировании сайта. Вероятно, у вас будет 50 установленных соединений.

Приложение rrdtool для отслеживания тенденций (например, Cacti, Munin или Ganglia), отображающее количество TCP-соединений, также хорошо подходит для отладки такого рода проблем, поскольку вы можете видеть исторические.

Надеюсь это поможет!