Первые шаги в нагрузочном тестировании, JMeter как выход из ситуации

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

Яндекс.Танк как первый лучик надежды

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

Яндекс.Танк компонуется с генератором нагрузки Phantom, при этом есть поддержка таких генераторов нагрузки, как JMeter, BFG и Pandora.

Пример структуры теста Phantom:

phantom:

address: 192.0.0.1:80

uris:

— /uri1

— /uri2

load_profile:

load_type: rps

schedule: const (10, 10 m)

Также в файле для запуска Яндекс.Танка указывается так называемый ammo файл, где указываются необходимые для теста GET и POST запросы.

Первым этапом нагрузочного тестирования после выбора инструмента стоит необходимость написания теста. Для этого был взят ключевой для проекта GET запрос, ответ которого должен содержать статус 200.

После генерации теста были первые неловкие попытки приступить к самому нагрузочному тестированию, то есть запустить тест в Яндекс.Танке с ammo-файлом, в котором и содержится информация о GET запросе.

Первые проблемы и поиск виновника

Результатом прогона теста была ошибка, ответ не был равен 200.

Прошерстив логи, сгенерированные при нагрузке, а также результаты запросов в логах стенда, был обнаружен нюанс с тем, что первым ответом, который приходит после запроса, является редирект, то есть статус 3xx, из-за чего генератор нагрузки Phantom выдает ошибку, он просто не может обработать редирект и дождаться статус 200.

JMeter решает проблемы

В поисках решения проблемы с обработкой редиректа Яндекс.Танком и генератором нагрузки phantom везде мелькала информация о JMeter.

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

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

JMeter встретил меня всем разнообразием своего интерфейса.

Для решения проблемы с редиректами в JMeter есть настройка обработки редиректов при тестировании HTTP реквестов.

Выбрав значение Redirect Automatically и сгенерировав файл с расширением jmx, было принято решение использовать данный файл с Яндекс.Танком, так как уже был понятен принцип запуска, работы и получаемых результатов в Яндекс.Танке.

Для работы Яндекс.Танка совместно с JMeter требуется, всего лишь, вместо Phantom в файле конфигурации добавить JMeter:

jmeter:

enabled: true

package: yandextank.plugins.JMeter

jmx: ammo.jmx

jmeter_path: /var/loadtest/apache-jmeter-3.3/bin/jmeter

buffered_seconds: 0

ext_log: none

variables:

protocol: http

host: 127.0.0.1

port: 8080

path: /path/to/endpoint

thread_rpm: 300

loops: 20

texts: scenarios.csv

Результат тестирования будет занесен в overload, который изначально рекомендуется использовать в Яндекс.Танк.

Результат был получен, и на тот момент он нас устраивал.

Новые задачи, новые открытия

Спустя время снова потребовалось провести нагрузочное тестирование. На сей раз требовалось сформировать Post-запрос и проверить, что ответ содержит определенную, изначально известную информацию.

Для этого потребовалось лишь в конфигурацию HTTP запроса добавить утверждение ответа.

Также из-за необходимости длительной отладки самого нагрузочного теста и возможности запустить нагрузку в самом JMeter было принято решение отказаться от Яндекс.Танка вовсе.

В связи с данным решением возникла необходимость в отчетности. Можно добавить, что тесты можно запускать с помощью JMeter как в графическом режиме, так и без него. Если запускать GUI, то результаты будут сохранены в логи, но гораздо важнее, как это сделать в графическом режиме, так как отладку легче проводить в графическом режиме. И здесь есть где разгуляться, от диаграмм и графиков до таблицы запросов и детальных данных каждого запроса, где присутствуют и данные запроса, и весь ответ.

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

Вывод

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