Apache Benchmark - параллелизм и количество запросов

Question

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

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

Complete requests: 1000000
Failed requests: 2617614

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

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

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

Answer 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 параллелизм, конечно, сужается до 0).

Имеет смысл?

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

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

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

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

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

Answer 2

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

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

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

Receive: 8409, Length: 8409, Exceptions: 8409