Гатлинг (и JMeter) пытаются поддерживать количество запросов в секунду (RPS)?

Question

Я загружаю тестирование API.У нас есть проблема - наше время отклика слишком велико, иногда близко к минуте.Мы хотим быть на расстоянии менее секунды.Но это не главное.

Когда я использую инструмент нагрузочного тестирования, такой как Gatling, отправленные RPS, похоже, останавливаются.Как вы можете видеть на прилагаемом изображении, начальные 15 секунд составляют 20 оборотов в секунду, а внезапно почти нет оборотов в секунду.Как я могу поддерживать постоянный RPS?Возможно, это связано с плохим временем отклика, но что, если мне наплевать на время отклика?Мне просто нужна константа RPS.

Мои первоначальные тесты с JMeter также показывают аналогичное поведение.

Answer 1

В JMeter этого можно достичь, используя Таймер постоянной пропускной способности на уровне плана тестирования.

Таймер постоянной пропускной способности позволяет вам поддерживать пропускную способность вашего сервера (запросов / сек). Таймер постоянной пропускной способности способен только приостанавливать потоки JMeter, чтобы замедлять их и достигать целевой пропускной способности. Кроме того, он работает только на минутном уровне, поэтому вам нужно правильно рассчитать период разгона и позволить вашему тесту работать достаточно долго.

Давайте посмотрим кратко об этом:

Для достижения целевой пропускной способности вам необходимо иметь достаточное количество потоков в плане тестирования.

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

RPS * максимальное время отклика в секундах

В вашем случае, если вам нужно 20 RPS и ваше максимальное время ответа составляет 60 секунд, вам нужно как минимум 1200 (20*60=1200) потоков в вашем плане тестирования.

Поскольку таймер постоянной пропускной способности работает на минутном уровне, для достижения значения 20 RPS необходимо настроить значение « Target Throughput » на 1200/min и «Рассчитать пропускную способность на основе» значение как "All active threads".

Конфигурация таймера с постоянной пропускной способностью:

Теперь, если в вашем плане тестирования имеется более одного запроса (т. Е. 4 requests), тогда 1200 requests/min будет распределено среди 4 samplers. Это означает, что вы получите 5RPS для каждого сэмплера.

Теперь для конфигураций Thread Group , как вы упомянули "Рассчитать пропускную способность на основе значения" в таймере постоянной пропускной способности для "All active threads", так что все ваши * Для достижения этого 20 RPS необходимо запустить 1049 * потоков на сервере. Используйте Ramp-Up Period config для контроля запуска этих потоков.

Период разгона - это время, в которое все потоки поступают на ваш протестированный сервер приложений. Так что, если вы используете 60 seconds, то для запуска всех ваших 1200 threads потребуется 60 секунд. 1200 потоков будут активны в 60 seconds.

Вам также необходимо соответствующим образом установить продолжительность теста. Скажем, вы хотите оставить это 20 RPS для 5 minutes. В этом случае вы должны установить продолжительность теста на 7 mins (дополнительно 2 минуты для: начиная с 1 минуты для 1200 потоков до запуска, что является временем разгона и последними 1 минутой для времени разгона 1200 потоков). Не забудьте проверить счетчик циклов до Forever, если вы используете Группа потоков .

Конфигурация группы потоков для вышеупомянутого сценария:

Вы также можете использовать другой удобный плагин JMeter, который является Ultimate Thread Group , если вас путают конфигурации по умолчанию Thread Group . Вы можете загрузить плагины JMeter с помощью JMeter Plugins Manager .

Вот конечная конфигурация группы потоков для вышеупомянутого сценария:

Теперь, когда тест завершен, вы можете проверить результаты 5 minutes, в которых все ваши 1200 потоков были активны, с помощью прослушивателей хитов в секунду , а также активных потоков с течением времени Слушатель .

Не используйте JMeter GUI для нагрузочного тестирования, используйте режим без графического интерфейса. Также удалите утверждения, если они есть в вашем плане тестирования, пока вы пытаетесь достичь некоторого целевого показателя RPS.

Answer 2

Какую стратегию инъекций вы используете? Как выглядит сценарий? Каждый пользователь делает один запрос, цепочку запросов или что-либо из перечисленного выше в цикле?

Предполагая, что вы хотите протестировать одну конечную точку, лучший способ получать постоянные запросы в секунду (а не постоянные ответы, как вы уже знаете) - это использовать сценарий, который выполняет один запрос, и стратегию, которая вводит постоянное количество пользователей в секунду, например:

setUp(
  scn.inject(constantUsersPerSec(25) during(15 minute))
)

Если ваш пользователь выполняет более 1 запроса, есть опция для уменьшения количества запросов, но вы должны помнить, что он будет только уменьшать, а не повышать, поэтому вы должны убедиться, что активные пользователи будут делать достаточно запросов в секунду, чтобы достичь этого. предел fe:

setUp(scn.inject(
  constantUsersPerSec(10) during(15 minutes)
).throttle(
  jumpToRps(25), holdFor(15 minutes)
))

Так вот, если fe. один пользователь делает 5 запросов, вы можете достичь даже 50 запросов / с, но он будет уменьшен до 25. Но вы должны помнить, что новые пользователи будут добавляться каждую секунду, поэтому, если для завершения 1 пользователя требуется больше времени, количество активных пользователей увеличится , Также, если время отклика велико, активные пользователи могут не выдавать достаточное количество запросов / с, так как большая часть их времени ожидает ответа.