Тест Apache - concurrency и количество запросов

В тестовой документации указано, что concurrency - сколько запросов выполняется одновременно, а количество запросов - общее количество запросов. Мне интересно, если я поставил 100 запросов на уровне concurrency 20, означает ли это 5 тестов по 20 запросам одновременно или 100 тестов по 20 запросов одновременно? Я предполагаю второй вариант, из-за приведенных ниже номеров примеров.

Мне интересно, потому что я часто вижу такие результаты, как этот, в некоторых тестовых блогах:

Complete requests: 1000000
Failed requests: 2617614

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

Изменить: сайт, который отображает вышеупомянутые номера: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

Или может быть, что он продолжает пытаться, пока не достигнет миллиона успешных результатов? Хм...

Ответ 1

Это означает, что один тест содержит всего 100 запросов, всегда сохраняя 20 запросов. Я думаю, что у вас есть неправильное представление о том, что запросы требуют всего того же количества времени, чего практически никогда не бывает. Вместо того, чтобы отправлять запросы в партиях по 20, ab просто начинает с 20 запросов и выдает новый каждый раз, когда заканчивается существующий запрос.

Например, тестирование с помощью ab -n 10 -c 3 начнется с3 одновременных запросов:

[1, 2, 3]

Скажем, что # 2 заканчивается первым, ab заменяет его четвертым:

[1, 4, 3]

... тогда # 1 может закончиться, заменить на пятый:

[5, 4, 3]

... Тогда # 3 заканчивается:

[5, 4, 6]

... и т.д., пока запрос не будет выполнен в общей сложности 10 запросов. (По завершении запросов 8, 9 и 10, concurrency сужается до нуля, конечно.)

Имеют смысл?

Что касается вашего вопроса о том, почему вы видите результаты с большим количеством сбоев, чем с полными запросами... Я не знаю ответа на этот вопрос. Я не могу сказать, что видел это. Можете ли вы опубликовать ссылки или тестовые примеры, которые показывают это?

Обновление: при поиске источника ab отслеживает четыре типа ошибок, которые подробно описаны ниже в строке "Failed requests:...":

Подключиться - (err_conn в источнике) Приращение, когда ab не настроит HTTP-соединение
Получить - (err_recv в источнике) Приращение, когда ab не удалось прочитать сообщение об ошибке
Длина - (err_length в источнике) Увеличивается, когда длина ответа отличается от длины полученного первого хорошего ответа.
Исключения - (err_except в источнике) Увеличивается, когда ab видит ошибку при опросе сокета подключения (например, соединение убито сервером?)

Логика вокруг, когда они происходят и как они подсчитываются (и как отслеживается итоговый счетчик bad), является, по необходимости, немного сложной. Похоже, что текущая версия ab должна учитывать только один раз за запрос, но, возможно, автор этой статьи использовал предыдущую версию, которая как-то считала более одного? Это мое лучшее предположение.

Если вы можете воспроизвести поведение, определенно укажите ошибку.

Ответ 2

Я не вижу ничего плохого. Неудачные запросы могут увеличивать более одной ошибки каждый. Это работает ab.

Существуют различные статически объявленные буферы фиксированной длины. В сочетании с ленивым анализом аргументов командной строки, заголовки ответов с сервера и другие внешние входы, это может вас укусить.

Вы можете заметить, например, что предыдущие результаты node имеют одинаковый счетчик для 3 счетчиков ошибок. Скорее всего, из 100 000 запросов было сделано только 8409, а не 25227.

Receive: 8409, Length: 8409, Exceptions: 8409