#jmeter #performance-testing #load-testing
#jmeter #тестирование производительности #нагрузочное тестирование
Вопрос:
я начал тестирование распределенной производительности с использованием jmeter. Если я приведу сценарий 1:
no.of threads: 10
ramp up period: 1
loop count: 300
Все проходит гладко, поскольку сценарий 1 преобразуется в 3000 запросов за 300 секунд. т. Е. 10 запросов в секунду.
Если я приведу сценарий 2:
no.of threads: 100
ramp up period: 10
loop count: 30
Afaik, scenario2 также выполняет 3000 запросов за 300 секунд, то есть 10 запросов в секунду.
Но начались сбои, т. Е. Сервер сталкивается с большой нагрузкой, и запросы завершаются сбоем. Теоретически и scenario1, и scenario2 должны быть одинаковыми, верно? Я что-то упускаю?
Все это тяжелые вызовы, каждый из которых займет 1-2 секунды при нормальной загрузке.
Ответ №1:
В идеальном мире для сценария 2 у вас будет 100 запросов в секунду, и тест завершится через 30 секунд.
Тот факт, что во 2-м случае у вас одинаковое время выполнения, указывает на то, что ваше приложение не может обрабатывать входящие запросы быстрее 10 в секунду.
Попробуйте увеличить время нарастания для 2-го сценария и посмотрите на следующие диаграммы:
Обычно при увеличении нагрузки количество «Транзакций в секунду» должно увеличиваться на тот же коэффициент, а «Время отклика» должно оставаться неизменным. Как только время отклика начинает расти, а количество транзакций в секунду начинает уменьшаться, это означает, что вы прошли точку насыщения и обнаружили узкое место. Вы должны сообщить о точке максимальной производительности и исследовать причины первого узкого места
Дополнительная информация: Какова взаимосвязь между пользователями и количеством обращений в секунду?
Ответ №2:
В сценарии 2 через 10 секунд у вас есть 100 одновременных пользователей, которые выполняют запросы параллельно, ваш сервер может плохо обрабатывать или предотвращать такую нагрузку
Одновременное пользовательское нагрузочное тестирование отправляет одновременный искусственный трафик в веб-приложение, чтобы нагружать инфраструктуру и регистрировать время отклика системы в периоды постоянной большой нагрузки.
В сценарии 1 через 10 секунд у вас есть 10 одновременных пользователей, выполняющих цикл по потоку, не вызывая нагрузки на сервер
Обратите внимание, что ваш сервер может иметь ограничение на количество пользователей, запрашивающих только определенные запросы
Комментарии:
1. Возможно, вы правы, но для меня это не имеет особого смысла. Не могли бы вы пояснить, почему у меня должно быть 100 одновременных пользователей через 10 секунд, когда период нарастания составляет 10 секунд?
2. период нарастания @rplusg — это время запуска всех пользователей, равное 1, если вы хотите запустить все за 1 секунду
Ответ №3:
Мы будем очень четко указывать время нарастания, следующее выдержка из официальной документации
Сценарий 1: количество потоков: 10 период нарастания: 1 количество циклов: 300
В приведенном выше сценарии 10 потоков (виртуальных пользователей) должны быть созданы за 1 секунду. Каждый пользователь будет выполнять цикл 300 раз. Следовательно, будет 3000 запросов к серверу. Пропускная способность не может быть рассчитана заранее с вышеуказанной конфигурацией. Это зависит от возможностей сервера, сети и т.д. Вы могли бы контролировать пропускную способность с помощью некоторых компонентов и плагинов.
Сценарий 2: количество потоков: 100 период нарастания: 10 количество циклов: 30
В сценарии 2 100 потоков (виртуальных пользователей) создаются за 10 секунд. 100 виртуальных пользователей будут одновременно отправлять запросы на сервер. Каждый пользователь отправит 30 запросов. Во втором сценарии у вас будет более высокая пропускная способность (количество запросов в секунду) по сравнению со сценарием 1. Похоже, сервер не может обрабатывать запросы 100 пользователей, отправляющих запросы одновременно.
Время нарастания применимо для первого цикла каждого потока. Это будет имитировать задержки между первым запросом каждого пользователя на их первой итерации.