Ликбез по "JMeter"

В прошлый раз мы бабахнули. Бабахать это хорошо, но бабахать с умом еще лучше. Дело в том, что phantom умеет хорошо генерировать нагрузку, но не умеет делать это с умом. В моей вселенной, нагружать конкретный узел(url, ресурс, etc.) 100500 миллионов хитов в секунду, нужно конечно, но очень редко. Основной вид/тип нагрузки, это сценарный. Когда необходимо эмулировать сценарий действий пользователей, которых может прийти несколько тысяч например. И вот тут у phantom начинаются проблемы. К phantom конечно можно привязать куку, и попробовать заставить его повторить действия пользователя, но в целом, поверьте мне, туго у него с этим. И тут на сцену выходит герой нашего опуса, великий и ужасный, всем известный, старый добрый Jmeter. Который к слову сказать на текущий момент имеет версию 3.1 В прошлый раз я упоминал, что яндекс.танк на самом деле обертка над генераторами нагрузки, и вполне может выступать таковым и для Jmeter. Сделать это легко и нагуглить как, не составит большого труда. Сегодня сконцентрируемся на JMeter. JMeter есть инструмент нагрузочного тестирования, который работает на JVM, имеет свой язык описания сценариев нагрузки, и даже графический UI. Разрабатывается Apache Foundation, имеет большое сообщество. Инструмент, реально мощный, умеет очень много протоколов, а те что не умеет из коробки, то есть возможность подключать плагины. Есть даже плагин - агрегатор плагинов, подключаешь и получаешь еще больше плагинов (https://jmeter-plugins.org/) их там много, 64 штуки, 64 плагина для инструмента нагрузочного тестирования, это поверьте мне много. Кстати он же умеет отключать плагины идущие с JMeter по умолчанию, что позволит избавиться 100500 ненужных пунктов контекстного меню при создания тест плана. Под тест планом, здесь и далее, понимается тот jmx файл, который в итоге получится, со сценариями и т.д. Установка проста, предполагается, что у вас стоит java 7й версии+ (у всех нормальных людей она уже стоит, если нет, то задумайтесь над тем как вам жить дальше).

Скачиваем бинарники, добавляем папку bin в PATH. Заходим в консоль и набираем jmeter жмакаем ENTER, и …. И видим самый ужасный интерфейс, который мог только придумать воспаленный мозг джависта. Но не беда, вы к нему привыкните, и даже полюбите, как только взгляните в xml подобный файл тест плана (jmx)... В первую очередь, добавляем кровь и плоть теста, это Thread Group. Thread Group можно воспринимать как некую сущность представляющую собой юзера, т.е. в него последовательно записываем те действия которые мы хотим чтобы пользователь выполнил. Для сложных сценариев, рекомендую воспользоваться рекордером HTTP(S) Test Script Recorder, как им пользоваться возможно расскажу после. В Thread Group можно добавить разные элементы, у них у всех разные сферы ответственности, рассмотрим их по группам:

1
Controllers

эти бывают двух видов: Samplers и Logic Controllers, первые отвечают за отправку запроса на сервер вторые за логические условия отправки этого запроса. Например логический контроллер Once Only Controller пригодится вам для выполнения запроса один единственный раз, например запроса авторизации.

1
Listeners

эти штуки предоставляют доступ к результатам теста.Они считывают результаты, и отображают его в удобоваримом виде. Есть графики, есть в дерева запросов/ответов. Собственно на любой вкус как говорится.

1
Timers

А вот это вот хитрые штуки. Как не парадоксально, но они по сути замедляют нагрузку. Нужно это для контроля этой самой нагрузки. Thread Group генерирует эту нагрузку по мере своих сил, а таймеры их ограничивают. Constant Timer например вставляет определенную постоянную задержку между запросами. А Constant Throughput Timer позволит вам к примеру добиться точной нагрузки в определенное количество запросов за определенное время и т.д.

1
Assertions

Головастый читатель, по названию может догадаться, что эти элементы служат для проверки, чего либо на что либо. И будет прав. Если вам нужно проверить, что именно пришло в ответе, assertion это то что вам надо (Response Assertion). Или вы хотите убедится, что ответ получен в течении определенного времени (Duration Assertion)

1
Configuration Element

Эти элементы позволят вам более гибко настроить ваш тест-план. Например подготовить переменные которые вам понадобятся в процессе теста, или же переопределить заголовки запросов (HTTP Header Manager).

1
Pre\Post processors

По названию можно догадаться, что эти элементы делают нечто до и после теста. Например считать что либо из БД до и записать обратно в БД после.

Этих элементов много, описывать все не входит в мои планы. На официальном сайте они достаточно хорошо описаны. Их многообразие и функциональность позволяет писать достаточно сложные сценарии. Комбинация вот этих вот элементов и позволяет создавать сценарии и профиль нагрузки. Это и есть тот самый язык написания сценариев, не самый удобный и наглядный, но на данный момент open source сообщество, что разрабатывает этот инструмент, ничего лучшего не придумало. Соединив все это добро вместе, мы получим так называемый тест план, используя который и тестируем приложение. Ну вот собрали вы свой тест план, что дальше? Дальше запускать, правило тут одно, не использовать JMeter GUI для нагрузки, GUI только для пристрелки, создания тест-плана и просмотра результатов. Для этого в Jmeter есть флаг -n то есть строка запуска будет примерно следующая:

1
jmeter -n -t my_test.jmx -l log.jtl

Где -t тест-план -l лог файл, который после теста можно скормить какому нибудь листенеру и посмотреть красивый график. На сегодня все, описать все возможности JMeter в рамках одной статьи невозможно, но я обещаю, что позже мы вернемся к нему.