Блог

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

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

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

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

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

 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 пользователем потребуется больше времени, количество активных пользователей увеличится. Также, если время отклика велико, активные пользователи могут не выдавать достаточное количество запросов, поскольку большую часть своего времени они ожидают ответа.

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

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

Давайте рассмотрим краткую мысль по этому поводу:

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

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

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

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

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

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

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

Теперь, для конфигураций группы потоков, как вы упомянули, «Вычислите пропускную способность на основе» значения в таймере постоянной пропускной способности для « All active threads «, поэтому все ваши 1200 потоки должны быть запущены на сервере для достижения этого 20 RPS . Используйте конфигурацию периода разгона для управления запуском этих потоков.

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

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

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

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

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

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

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