В прошлый раз мы бабахнули. Бабахать это хорошо, но бабахать с умом еще лучше. Дело в том, что phantom умеет хорошо генерировать нагрузку, но не умеет делать это с умом. В моей вселенной, нагружать конкретный узел(url, ресурс, etc.) 100500 миллионов хитов в секунду, нужно конечно, но очень редко. Основной вид/тип нагрузки, это сценарный.

Когда необходимо эмулировать сценарий действий пользователей, которых может прийти несколько тысяч например. И вот тут у phantom начинаются проблемы. К phantom конечно можно привязать куку, и попробовать заставить его повторить действия пользователя, но в целом, поверьте мне, туго у него с этим. И тут на сцену выходит герой нашего опуса, великий и ужасный, всем известный, старый добрый Jmeter. Который к слову сказать на текущий момент имеет версию 3.1 В прошлый раз я упоминал, что яндекс.танк на самом деле обертка над генераторами нагрузки, и вполне может выступать таковым и для Jmeter. Сделать это легко и нагуглить как, не составит большого труда. Сегодня сконцентрируемся на JMeter.

Установка JMeter на Windows

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

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

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

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

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

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

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

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

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

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

Где тест-план лог файл, который после теста можно скормить какому нибудь листенеру и посмотреть красивый график.

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

Часть 1. Записываем сценарий в jMeter

Самый простой способ записать сценарий обращения к серверу приложений при работе пользователя — это отловить все запросы идущие от браузера. В этом нам поможет элемент HTTP-Proxy Server:

Настраиваем HTTP-Proxy Server

1. Добавляем новую группу в Test Plan — туда будут помещаться запросы к серверу
2. Добавляем HTTP-Proxy Server
3. Настраиваем HTTP-Proxy Server:
   • Выбираем созданный Thread Group в Target Controller
   • В Grouping выбираем "Add separators between groups" для того чтобы запросы друг от друга отделялись элементом "———-".
   • Добавляем в URL Paterns паттерны для отсеивания картинок, скриптов и стилей (.*\.jpg, .*\.gif, .*\.png, .*\.js, .*\.css)

   

4. Жмем кнопку Start
5. Теперь настраиваем браузер. Например в firefox в меню Инструменты > Настройки > Дополнительно > Сеть > Настроить проставляем HTTP прокси localhost и порт 8080

После этого все запросы с браузера будут записываться в jMeter.

Настраиваем сценарий

Для того, чтобы сервер понял, что все запросы на самом деле поступают от одного и того же пользователя, необходимо включить cookie. Сервер запишет в них ID сессии по которой дальше и будет определять, от кого идут запросы. Для этого надо добавить Cookie Manager (Add > Config Element > HTTP Cookie manager) перед выполнением всех запросов. Чтобы куки очищались при каждом запуске не забудьте включить опцию "Clear cookies each iteration".

После этого можно размещать запросы страниц. 

Отправка заполненных форм

Запуск записанного сценария скорее всего приведет к неудаче. Причина проста — в формах и в ссылках wicket генерирует уникальные сслыки. Как можно решить эту проблему рассмотрим на примере формы входа в систему.

Изначально заполненная форма отправляется на длинный адрес следующего вида:

…
<form action="?wicket:interface=:0:signInForm::IFormSubmitListener::"
id="signInForm1" method="post">
…

Где signInForm — это wicket:id нашей формочки, а все остальное формируется динамически библиотекой wicket.

Для того, чтобы jMeter мог определить на какую страницу ему посылать логин с паролем, нам нужно к запросу страницы login добавить обработчик Regular Expression Extector (Add > Post Processors > Regular Expression Extector).

Apache jMeter – нагрузочное тестирование веб-сервера

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

"([^"]+:signInForm:[^"]+?)"

где signInForm — это wicket-id формы.

Кроме выражения в настройках Regular Expression Extector нужно указать имя переменной и шаблон (Template). В нашем случае нам нужно выбрать все что находится в кавычках — а это первая группа в регулярном выражении. Соответственно шаблон будет выглядеть как $1$. Кроме этого можно указать какое найденное выражение следует использовать (Match No).

Теперь мы может отсылать post-запрос добавив в Path нашу переменную (Например /login${loginFormUrl}).

Переход по ссылкам

После того, как мы залогинились, можно и по сайту побродить. Но wicket формирует ссылки динамически! Отследить сслыку нам поможет все тот же Regular Expression Extector. При этом следует помнить два нюанса:

1. В регулярном выражении лучше всего использовать wicket-id элемента вместе со всеми wicket-id родительских элементов. Например, если элемент tabs размещается внутри tabbed_panel, то ссылка этого элемента будет вида "([^"]+tabbed_panel:tabs:[^"]+?)"
2. Списки (ListView) генерирует для элементов идентификаторы в виде порядкого номера. Этим можно воспользоваться для перехода на произвольный элемент списка, задав в параметре Match No — 0, а в качестве регулярного выражения — выражение, содержащее идентификатор списка (без конкретного номера).

Задержки

HTTP-Proxy записывает сценарий без учета задержек пользователя на освоение информации и ввод данных. Для эмуляции этих действий можно задействовать элемент "задержка" (Timer). Так как, для разных пользователей время "задержки" будет разным — то имеет смысл добавить элемент Gaussian Random Timer (Add > Timer > Gaussian Random Timer). Он позволяет задать среднее время задержки и разброс.

Сохранение результата запроса

Иногда бывает полезно проверить, что возвращает сервер в результате того или иного запроса. Сделать это можно при помощи элемента Save Responses to a file (Add > Post Processors > Save Responses to a file), При этом, если у запроса включена опция Follow Redirects, то jMeter сохранит все ответы сервера добавляя к указанному префиксу номер ответа.

Еще почитать про jMeter

1. Официальный мануал
2. Wicket and JMeter with Regular Expressions
3. Набор tutorial для jMeter