В контрольной документации указано, что параллелизм – это то, сколько запросов выполняется одновременно, а количество запросов – общее количество запросов. Мне интересно, если я поставил 100 запросов на уровне параллелизма в 20, означает ли это 5 тестов по 20 запросам одновременно или 100 тестов по 20 запросов одновременно? Я предполагаю второй вариант, из-за приведенных ниже номеров примеров ..
Мне интересно, потому что я часто вижу такие результаты, как этот, в некоторых тестовых блогах:
Complete requests: 1000000 Failed requests: 2617614 Это кажется неправдоподобным, так как количество неудачных запросов больше, чем количество полных запросов.
Изменить: сайт, который отображает вышеупомянутые номера: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache–php
Или может быть, что он продолжает пытаться, пока не достигнет миллиона успешных результатов? Хм …
Это означает, что один тест содержит 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, параллелизм сужается до нуля, конечно.)
Имеют смысл?
Что касается вашего вопроса о том, почему вы видите результаты с большим количеством сбоев, чем с полными запросами … Я не знаю ответа на это. Я не могу сказать, что видел это. Можете ли вы опубликовать ссылки или тестовые примеры, которые показывают это?
Обновление: при просмотре источника ab отслеживает четыре типа ошибок, которые подробно описаны ниже в строке «Failed requests: …»:
err_conn in source) Приращение, когда ab не может настроить HTTP-соединение err_recv в источнике) Приращение, когда ab не удается прочитать соединение, не удается err_length в источнике) Увеличивается, когда длина ответа отличается от длины полученного первого полученного отклика. err_except в источнике) Приращение, когда ab видит ошибку при опросе сокета подключения (например, соединение убито сервером?) Логика вокруг того, когда они происходят и как они учитываются (и как отслеживается общее количество ошибок), является, по необходимости, сложной. Похоже, что текущая версия ab должна учитывать только один раз за запрос, но, возможно, автор этой статьи использовал предыдущую версию, которая как-то считала более одного? Это мое лучшее предположение.
Если вы можете воспроизвести поведение, обязательно укажите ошибку .
Я не вижу ничего плохого. Неудачные запросы могут увеличивать более одной ошибки каждый. Вот как работает ab .
Существуют различные статически объявленные буферы фиксированной длины. В сочетании с ленивым разбором аргументов командной строки, заголовками ответов с сервера и другими внешними входами, это может вас укусить.
Например, вы можете заметить, что предыдущие результаты узла имеют одинаковый счетчик для 3 счетчиков ошибок. Скорее всего, из 100 000 запросов было сделано только 8409, а не 25227.
Receive: 8409, Length: 8409, Exceptions: 8409