- Приручаем JMeter
- Установка
- Запись скрипта
- Переменные
- Отладка
- JDBC Request
- Регулярные выражения
- Что-то там внутри
- Запуск
- Использование JMeter для организации распределенной нагрузки
- Нагрузочное тестирование «не-HTTP». Ч.1 JMeter
- Почему JMeter и Gatling
- JMeter
- Cравнение производительности sampler
- Java Request Sampler
- Junit Request Sampler
- Пишем Thrift клиент
- JMeter без jmx
- Предельная нагрузка
- Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter
- Настройка JMerter
- Создание тест-плана
- Запуск теста и просмотр результатов
Приручаем JMeter
Сегодня я хочу рассказать о замечательном инструменте, название которого вынесено в заголовок статьи. Разумеется, моей целью не является написание подробного руководства по Apache JMeter. В своей статье я хочу лишь зафиксировать ряд, на мой взгляд, не очевидных моментов, с которыми мне пришлось столкнуться в своей повседневной работе. Я надеюсь, что моя статья будет полезна (сразу предупреждаю, картинок будет много).
Конечно, я не первый, кто пишет про JMeter на Хабре, но практически во всех предыдущих статьях, акцент делается на нагрузочное тестирование. Хотя это и основное применение JMeter, но только им его возможности не ограничиваются. Давайте, просто посмотрим, по каким протоколам может работать этот продукт:
Установка
Запись скрипта
Это, пожалуй, самая эффектная возможность JMeter. Она уже описывалась ранее, но я повторюсь, поскольку в той статье речь шла об уже немного устаревшей версии. JMeter можно запустить в режиме proxy, таким образом, чтобы весь HTTP-трафик проходил через него. Все подробности взаимодействия будут автоматически записываться в выбранную Thread Group или Recording Controller. Для добавления новых узлов в дерево, просто нажимаем на правую кнопку мыши и выбираем требуемый тип из выпадающего меню:
Thread Group, управляющая такими настройками как количество потоков, используемых для тестирования и количество запросов в тесте, находится в категории Treads (Users), а сам HTTP(S) Test Script Recorder в Non-Test Elements.
Я выделил на рисунке настройки, на которые следует обратить внимание. Порт возможно придётся изменить, если на 8080 уже что-то поднято. В сложных случаях, в Test Plan придётся добавить HTTP Cookie Manager и HTTP Authorization Manager. После нажатия кнопки Start, идём в настройки любимого браузера:
Взаимодействие с Яндекс, внезапно, оказывается очень непростым:
Полученные запросы (HTTP Request) вместе с их настройками (HTTP Header Manager) можно перенести в любое место скрипта, используя любимые всеми команды Copy&Paste (Drag&Drop тоже работает). Даже если вы твердо уверены в том, что происходит на вашем сайте, Script Recorder может быть очень полезен, для того чтобы узнать подробности. Кроме того, автоматическая генерация скриптов куда веселее чем вбивание их руками. Более подробно процесс записи скриптов описан в этой инструкции.
Переменные
Для чего-то мало-мальски серьёзного, нам потребуется возможность параметризации. Для примера, предположим, что нам требуется задать таймауты, в течение которых JMeter будет ожидать ответа сервера. Вбивать их заново в каждый HTTP Request, при любом изменении, было бы слишком утомительно. Заодно определим настройки HTTP Proxy (если он используется):
Пустые значения переменных проблемой не являются. В соответствующие настройки будут подставлены пустые строки, как того и требуется, в случае если HTTP Proxy не используется. Можно пойти ещё дальше и действительно разместить все HTTP-настройки в одном месте:
Элемент HTTP Request Defaults, также как и User Defined Variables расположен в категории Config Element.
Отладка
Теперь, было бы неплохо видеть, что происходит при выполнении сценария. Различного вида визуализаторы размещаются в категории Listener. Нам понадобится View Results Tree. Добавим его и запустим сценарий на выполнение командой Run/Start (Ctrl+R). Можно видеть, что ответ сервера также бывает непростым:
Такая картина наблюдается, если адрес редиректит нас на другую страницу и с этим может быть связана одна проблема. Если мы попытаемся анализировать ответ сервера (как это делать я покажу ниже), нам будет доступен лишь последний ответ (той страницы на которую произошёл redirect). Если ответ с предыдущей страницы нам также интересен, автоматический redirect придётся отключить. За это отвечает настройка Follow Redirects элемента HTTP Request. Разобрав ответ, мы сможем получить адрес целевой страницы и выполнить повторный запрос вручную.
Есть ещё один элемент, крайне полезный для отладки сценариев. Он находится в категории Sampler и называется Debug Sampler. Каждый раз, когда до него доходит управление, он выводит текущие значения всех переменных. Добавим его в Thread Group и запустим сценарий ещё раз (для того, чтобы очистить вывод предыдущего запуска, удобно использовать комбинацию клавиш Ctrl+E):
Все переменные как на ладони. Удобно.
JDBC Request
Этот Sampler открывает нам доступ в любую базу данных, поддерживающую протокол JDBC. Для начала, добавим в Test Plan конфигурационный элемент с настройками подключения к серверу БД (JDBC Connection Configuration):
Помимо собственно настроек подключения к БД, здесь важно заполнить поле Variable Name. Это имя будет использоваться в JDBC Request (Sampler) для доступа к пулу сессий:
Если вам интересны результаты select-а, придётся заполнить Variable Names. Сам JMeter парсить SQL-запросы на предмет имён столбцов не умеет. Можно перечислять имена столбцов через запятую и пропускать столбцы, не давая им имени. Вставляем Debug Sampler и смотрим, что получилось:
Видим, что документация не врёт. Появились переменные urls_1 и urls_2 (количество строк, как и обещали, в urls_#). В этом месте, стоит соблюдать осторожность. Записи выбираются не по одной, а все сразу и прочитав >1000 строк можно легко отожрать слишком много памяти. Теперь, было бы неплохо обойти полученные адреса в цикле:
Да, именно вот так заковыристо. Набор переменных urls перебираем от 0 до $ и текущее значение помещаем в url. Сам ForEach Controller можно найти в категории Logic Controller. Внутри него создадим параметризованный HTTP Request. Запускаем, смотрим:
Регулярные выражения
Теперь, результаты обращений к Web-серверам хотелось бы проанализировать. Для этого, нам предоставлена вся мощь регулярных выражений. Regular Expression Extractor можно найти в Post Processors. Добавим его в HTTP Request и сконфигурируем:
Здесь, нас интересует только код ответа по HTTP (но, по иллюстрации видно, что можно обрабатывать и содержимое ответа). Будем извлекать цепочку цифр (Regular Expression) и помещать результат применения шаблона (Template) в переменную http_result (Reference Name):
Как и ожидалось, получаем 200. Заодно, можно видеть, каким образом осуществляется захват в переменные регулярным выражением.
Что-то там внутри
Теперь, допустим, что нас интересует время, в течение которого выполнялся HTTP-запрос. И интересует оно нас не просто для статистики, а мы его хотим как-то использовать в сценарии (например сложить в БД). С этой задачей поможет справиться BeanShell. Конкретно, мы используем его Pre — и PostProcessor-ы.
В первом будем получать timestamp:
А во втором, получать с его помощью временную задержку:
В общем, это тоже работает:
Но здесь следует сделать важное замечание. Поскольку, в настоящий момент, я занимаюсь не нагрузочным тестированием, производительность этой конструкции для меня не очень важна. Если в вашем случае это не так, стоит ознакомиться со следующей статьёй.
Запуск
Если бы не было этой возможности, не стоило бы и весь этот разговор заводить. В случае нагрузочного тестирования, сценарий можно запускать из GUI, нет проблем. Но если нас интересует автоматизация, необходимо уметь запускать его молча (например по cron-у). Разумеется такая возможность тоже есть:
Сохраняем сценарий в файл с расширением jmx (внутри это XML) и запускаем эту команду. Сценарий отрабатывает без запуска GUI и заодно пишет результаты своей работы в лог. Всё просто и удобно.
Использование JMeter для организации распределенной нагрузки
Автор: Роман Денисенко, старший инженер по тестированию DataArt.
Введение
Довольно часто при тестировании производительности возникает задача нагрузить слишком высокопроизводительную систему, способную без проблем переваривать огромное количество одновременных запросов. Или возможна ситуация, когда подопытная система очень чувствительно относится к источнику нагрузки, балансируя свои вычислительные мощности в зависимости от географического расположения клиентов.
Для генерации такой нагрузки возможностей одной тестовой машины становится уже недостаточно. И тогда возникает классический вопрос — как можно воспроизвести подобную нагрузку с минимумом затрат и максимумом результата.
К счастью, большая часть современных программных средств, используемых для нагрузочного тестирования, позволяет использовать дополнительные удаленные агенты, необходимые для эмуляции распределенной нагрузки. В рамках данной статьи я хотел бы рассмотреть возможность создания нагрузочного кластера на примере, думаю, одной из самых распространенных программ, используемых тестировщиками, — великого и ужасного Apache JMeter`а.
Теория
Думаю, многие знакомы с возможностями JMeter (если это не так, для начала крайне советую почитать какие-либо базовые статьи по основному функционалу этой программы), поэтому я хотел бы больше сфокусировать именно на применимости JMeter для распределенной нагрузки.
Для начала давайте обратимся к терминологии, принятой создателями JMeter. А терминология у них, если честно, довольно странная. В терминах JMeter, сервер, который управляет нагрузкой, называется «клиент». Агенты, которые получают команды с главного сервера и осуществляют нагрузку, называются «сервер». Лично мое мнение, эта терминология немного инверсна, но оставим ее на совести создателей. В статье я буду пользоваться именно этими терминами. Типичную инфраструктуру распределенной нагрузки, созданную при помощи JMeter, можно легко представить на изображении ниже.
Логика распределенной нагрузки довольно простая: клиент посылает указанный набор тестов на каждый из серверов, а серверы, в свою очередь, выполняют эти тесты и отправляют собранные результаты обратно клиенту, который суммирует полученную информацию и выводит ее конечному пользователю. Таким образом, разница в том, какое количество агентов мы используем для нагрузки, не особо видна, и мы можем работать точно так же, как раньше с одной машиной.
Рабочий процесс:
Для того чтобы заставить JMeter видеть удаленных агентов и иметь возможность контактировать с ними, следует выполнить следующие шаги:
1. Download. Нужно загрузить последнюю версию JMeter c официального сайта. Архив содержит обе версии — и клиентскую, и серверную. Зависимость того, как запустится JMeter, как сервер или как клиент, определяется с помощью ключей, передаваемых при запуске главного исполняемого файла программы. Стоит учесть самый главный момент — версии сервера и клиентов должны совпадать!
2. Installation. После этого следует разархивировать скачанный архив на машины, на которых хотим запустить клиента и серверы распределенной нагрузки. Один из положительных моментов — JMeter позволяет использовать неограниченное количество серверов, подключенных к одному клиенту. Но есть важное ограничение — все машины должны лежать в рамках одной подсети. Для облачных решений это довольно легко решаемо использованием VPN-соединений:
3. Servers. Теперь следует запустить сервера распределенной нагрузки. Делается это довольно легко. Для этого необходимо выполнить сценарий bin/jmeter-server (.bat в случае Windows), расположенный в корне папки с программой.
Примечание: Иногда Java неправильно определяет IP-адрес сервера — в этом случае вы увидите исключение в логе jmeter-сервера, которое будет указывать, что IP-адрес отличается от того, который вы хотите использовать. Тогда можно назначить ему другой IP. Для этого запустите сервер со следующим параметром: -Djava.rmi.server.hostname=[IP].
4. The client. После запуска всех серверов нужно настроить и сам клиент, который будет управлять нагрузкой. Чтобы заставить клиент найти все запущенные серверы, требуется добавить IP-адреса данных серверов в свойство remote_hosts в файле bin/jmeter.properties:
remote_hosts=192.168.0.1:1099, 192.168.0.2:1098
Примечание: номер порта — дополнительный параметр. По умолчанию сервер использует порт 1099 — однако вы можете назначить его вручную.
6.
Заключение.
Проделав все эти довольно простые шаги, вы сможете эмулировать какую угодно большую нагрузку, используя для этого мощь удаленных серверов. Желаемая нагрузка будет ограничиваться лишь количеством свободных серверов в вашем распоряжении и вашей же фантазией.
Нагрузочное тестирование «не-HTTP». Ч.1 JMeter
В монолите вызовы методов делались внутри одного приложения — теперь, в микросервисной архитектуре, всё взаимодействие осуществляется через сеть. Соответственно, скорость обмена информации между приложениями падает вне зависимости от используемого протокола обмена.
В этой статье мы расскажем, как писать код для нагрузочного тестирования «не-HTTP» протоколов на примере Apache Thrift с помощью таких инструментов, как JMeter и Gatling (часть 2). Тестировать будем микросервис, который должен справляться с 50K RPS. С одной нагрузочной машины постараемся достичь производительности, заявленной в этом твите:
Successfully tested #thrift protocol based service with #JMeter, got 14K responses per second. Thrift API is very nice to use in TCPClient
Мы берем за основу Thrift, но это не играет особой роли, с небольшими корректировками можно тестировать gRPC, Avro и другие протоколы. Подходы в статье общие, и необходимо будет только заменить клиента.
Формально, описанные протоколы это RPC framework and/or data serialization system, но даже сами разработчики употребляют слово protocol.
Почему JMeter и Gatling
Одна из причин — opensource-происхождение. Можно заглянуть в код и попытаться понять, что и как реализовано в инструменте. И платить не надо.
На просторах GitHub существуют заточенные под конкретные протоколы инструменты. Например, для Thrift это Iago от разработчиков Twitter или Bender от ребят из Pinterest. Но работа с такими фреймворками резко увеличивают порог вхождения и bus factor. В отличие от них Gatling и тем более JMeter широко распространены и имеют большое комьюнити, у которого всегда можно попросить совет или найти описание проблемы.
Ну и нам, как любителям писать код в любой непонятной ситуации, оба инструмента отлично подходят.
Следующий вопрос: почему бы не взять один из двух инструментов? На первый взгляд мы имеем паритет между ними и хотим понять всё в деталях: какой работает лучше, у кого какие проблемы. Кроме того, интересно сопоставить подходы — Threads vs Actors.
JMeter
Хотя JMeter и является GUI-ориентированным средством нагрузки, для него можно писать код. Такой подход улучшает читаемость, позволяет хранить данные в адекватном виде в VCS и проводить code review без боли в глазах. К тому же для написания клиента для любого протокола, код является не только достаточным, но и необходимым условием. Наконец, с кодом легко обратиться к разработке за помощью, не рассказывая им о конкретном инструменте, и тем самым опять же понизить bus factor.
Посмотрим, что JMeter предлагает для нагрузки кастомных протоколов:
Cравнение производительности sampler
Чтобы понять, какой sampler использовать, проведем сравнительный анализ. Для тестирования напишем простенький скрипт, который соединяет строки в цикле, и установим VALUE маленьким (10) и побольше (100).
Все тесты проводились на версии JMeter 3.3:
Видно, что JSR223 работает медленнее, значит, он вылетает. У Java и Junit схожая производительность, чтобы понять, какой удобнее, придется разбирать оба.
Java Request Sampler
Java Sampler имеет всего две настройки: выбор теста для нагрузки и параметры для передачи в тест. Можно задать набор дефолтных параметров в коде — они появятся в GUI JMeter. Но следует учесть, что после добавления нового параметра прямо из GUI и сохранения тест-плана только что добавленные параметры сбросятся.
Java Sampler тест расширяет стандартный AbstractJavaSamplerClient из библиотеки JMeter (которую подключаем любым удобным для вас средством сборки, например, Gradle). Собственно, тестовый класс может состоять из самого теста, пред- и постусловий и параметров по умолчанию.
Тестовый метод принимает контекст JMeter, из которого следует брать параметры, и возвращает SampleResult, который, в свою очередь, содержит совокупность методов, помогающих настраивать тестовый прогон и оценивать результаты. Для наших целей важны 3 приведенных метода: время старта и окончания запроса, а также результат.
Junit Request Sampler
Junit Sampler также имеет выбор теста для нагрузки и здесь в одном классе можно написать несколько методов. Дефолтные параметры пробрасываются в код через элемент User Defined Variables. Все остальные настройки понятны из описания: не вызывать пред- и постусловий, добавлять в вывод assert-ы и ошибки выполнения. Не стоит включать создание экземпляра теста для каждого нового запроса, так как это значительно затормозит производительность.
Junit Request Sampler похож на обычный Junit тест, но работает немного по-другому. JMeter никогда не вызывает @BeforeClass и @AfterClass, поэтому для настройки глобального предусловия необходимо использовать отдельный тест. Еще стоит заметить, что код из Before и After не учитывается во времени прогона теста.
Сами разработчики JMeter говорят, что GUI-режим следует использовать только для дебага. Но и тут надо быть осторожным со статиками и синглтонами. Например, после повторного запуска теста всё, что объявляется внутри синглтона, не будет инициализировано. В то же время без использования синглтона все объекты будут заново инициализироваться перед каждым тестом, что пагубно скажется на производительности. Статические переменные навсегда запомнят свои значения после запуска теста и не изменятся, даже если их переопределить из GUI.
Сравнив оба sampler, мы в итоге остановились на Junit Request Sampler за его простоту и, в то же время, легкость модификации.
Пишем Thrift клиент
При написании клиента следует учесть всё многообразие настроек протокола Thrift. Главное правило: клиент и сервер должны работать с одинаковыми транспортом и протоколом, иметь одну версию артефактов.
Чтобы не тратить время на создание клиента в каждом тесте и не исчерпать порты машины, с которой генерируем нагрузку, напишем сразу пул клиентов. Для пула можно указать количество клиентов, он сам будет держать нужное количество подключений, необходимо будет только брать клиента из пула перед использованием и возвращать после.
Вот так мы создали пул и клиент. Главное, что в данном примере пул ничего не знает про реализацию, и конфигурируется при создании. Это самый базовый пул, написанный на GenericObjectPool, на его основе наши разработчики сделали саморегулирующийся пул с логированием и единым протоколом/транспортом.
Написали код, соберем его в jar файлы и положим рядом с JMeter:
Следует не забыть и про сторонние библиотеки и их уникальность. Без них тест может даже не появиться в списке доступных или получить конфликт версий при запуске нагрузки.
JMeter без jmx
Статья о написании кода для JMeter будет неполной, если мы не обсудим, как избавиться от громоздких тест-планов на сотни строк XML в jmx файлах.
Напишем приложение с помощью библиотек JMeter и пройдемся по основным моментам по порядку.
Перед запуском приложения необходимо указать, где живут настройки для JMeter. При этом локально устанавливать JMeter необязательно:
Назовем наш тест план и укажем протокол:
LoopController и ThreadGroup отвечают за генератор нагрузки — как и сколько будем грузить. Тут всё стандартно:
Результаты в сжатом виде можно видеть в течении нагрузки (благодаря summariser), а затем сохранить их для последующей обработки (за это отвечает resultCollector):
Все элементы объединены в специальное JMeter дерево. Похоже на то, как мы это делаем в GUI моде:
Конфигурируем и запускаем нагрузку:
Все, можно забыть об XML. Ура!
Предельная нагрузка
Посмотрим, сколько сможет выдать наш генератор с одной нагрузочной машины. Естественно, все настройки системы для нагрузочного тестирования произведены, мы уже поколдовали с настройками сети и увеличили лимиты на открытые дескрипторы. После прогона получаем не очень ровный график нагрузки, согласно которому мы можем сделать около 30K RPS:
Естественно встает вопрос, это предел клиентской или серверной части? Мы поставили рядом еще один JMeter в кластере и убедились, что сервис может выдать целевые 50 тысяч RPS.
В следующей части мы разберем нагрузку «не-HTTP» с помощью Gatling, и расскажем, как нам удалось увеличить его производительность в десятки раз.
Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter
Крупные распределенные информационные системы зачастую состоят из более мелких модулей (подсистем) и разрабатываются группами программистов с использованием разных платформ и подходов. Часто, обмен данными в таких системах происходит в асинхронном режиме и предпочтительно использование промежуточного программного обеспечения, ориентированного на обработку сообщений (англ. Message-Oriented Middleware, MOM).
Для модульного и интеграционного тестирования таких систем удобно использовать старый добрый Apache JMeter.
Для примера выделим небольшой стандартный модуль такой системы. Допустим, есть некий адаптер, который читает XML сообщение из очереди входящих сообщений, выполняет преобразование структуры XML сообщения и публикует преобразованное сообщение в очередь исходящих сообщений. В качестве MOM, в данном случае, используется Websphere MQ 7.5.
Настройка JMerter
Для ручного тестирования такой системы можно использовать утилиту rfhutil, которая поставляется с Websphere MQ. Однако, если вариантов преобразования структуры XML документа много, то проверка таких изменений “руками” не оправдана. Есть большой риск не найти ошибку.
Для тест плана нам потребуются следующие элементы: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber. Для того, чтобы в JMeter появилась возможность использовать элементы JMS Publisher, JMS Subscriber необходимо добавить jar библиотеки в папку %jmeter_home%/lib/ext в зависимости от того, какое MOM вы используете.
В случае Websphere MQ 7.5 необходимые jar библиотеки находятся в директории %wmq_home%/java/lib.
Запуск классов WebSphere MQ для администрирования JMS
InitCtx> DEF CF(LOCAL.QCF) QMGR(TEST.QM) TRANSPORT(CLIENT) HOSTNAME(localhost) PORT(1415)
InitCtx> DEF Q(QUEUE.IN) QMGR(TEST.QM) QUEUE(QUEUE.IN)
InitCtx> DEF Q(QUEUE.OUT) QMGR(TEST.QM) QUEUE(QUEUE.OUT)
InitCtx> end
Остановка классов WebSphere MQ для администрирования JMS
Создание тест-плана
Наш тест план содержит несколько базовых элементов: User Defined Variables, Thread Group, JMS Publisher, JMS Subscriber, View Results Tree.
Элемент User Defined Variables содержит параметры подключения к MQ инфраструктуре.
Элемент JMS Publisher содержит настройки для работы с MQ очередью (режим запись). Есть несколько способов указать, какое сообщение должно быть записано в очередь. В данном примере для простоты сообщение публикуется непосредственно в шаге сценария.
Элемент JMS Subscriber содержит настройки для работы с MQ очередью (режим чтение).
Запуск теста и просмотр результатов
Чтобы проверить, что наш тест работает так как нужно очистим очереди сообщений, с которыми будем работать. В ту очередь, из которой тест будет читать сообщения, поместим тестовое сообщение с содержимым “Hello, Habrahabr!”
