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

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

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

Complete requests: 1000000
Failed requests: 2617614

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

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

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

Author: Swader, 2011-10-05
Source

2 answers

Это означает один тест с общим количеством запросов 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 отслеживает четыре типа ошибок, которые подробно описаны ниже строки "Неудачные запросы:...":

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

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

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

 34
Author: broofa, 2011-10-11 13:14:41

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

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

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

Receive: 8409, Length: 8409, Exceptions: 8409
 0
Author: dresende, 2011-10-12 22:57:40