Как запустить jmeter из командной строки windows

Обновлено: 08.07.2024

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

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

Установка

С этим всё просто:

Устанавливаем Java (если она еще не установлена)
Выкачиваем и распаковываем свежую сборку JMeter
Устанавливаем переменную среды JMETER_BIN на каталог с исполняемыми файлами JMeter (только для Windows)
Запускаем jmeter.bat или jmeter.sh (в зависимости от операционной системы) из каталога bin

Запись скрипта

Взаимодействие с Яндекс, внезапно, оказывается очень непростым:

Переменные

В поле Password забито значение $ , тут уж вам придётся поверить мне на слово. Сами настройки удобно держать в User Defined Variables (этот элемент можно найти в категории Config Element):

Отладка

Теперь, было бы неплохо видеть, что происходит при выполнении сценария. Различного вида визуализаторы размещаются в категории Listener. Нам понадобится View Results Tree. Добавим его и запустим сценарий на выполнение командой Run/Start (Ctrl+R). Можно видеть, что ответ сервера также бывает непростым:

Есть ещё один элемент, крайне полезный для отладки сценариев. Он находится в категории 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 и смотрим, что получилось:

Регулярные выражения

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

Что-то там внутри

В первом будем получать timestamp:

А во втором, получать с его помощью временную задержку:

В общем, это тоже работает:

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

Запуск

Если бы не было этой возможности, не стоило бы и весь этот разговор заводить. В случае нагрузочного тестирования, сценарий можно запускать из GUI, нет проблем. Но если нас интересует автоматизация, необходимо уметь запускать его молча (например по cron-у). Разумеется такая возможность тоже есть:

Сохраняем сценарий в файл с расширением jmx (внутри это XML) и запускаем эту команду. Сценарий отрабатывает без запуска GUI и заодно пишет результаты своей работы в лог. Всё просто и удобно.

В этом посте я опишу, как создать нагрузочный тест веб-приложения с помощью инструмента для проведения нагрузочного тестирования, разрабатываемого в рамках Apache Jakarta Project — JMeter.

Запустив программу, слева видим 2 пункта — Test Plan и WorkBench. Добавим Thread group в Test plan, для этого нужно нажать правой клавишей на Test plan — Add — Threads (Users) — Thread group.

Далее очистим проект он ненужной информации. Некоторые пакеты ссылаются к сторонним сервисам, на которые нам не нужно создавать нагрузку. Их нужно удалить. Для этого нужно перебрать их все и посмотреть, какое указано значение Server Name or IP. Если имя сервера не имеет отношения к тестируемому ресурсу — мы не создадим на него дополнительной нагрузки. Такие url удаляем (нажатием del):

А такие оставляем:

Добавим в Thread Group по очереди элементы просмотра. Нажимаем правой клавишей на Thread Group — Add — Listener — Graph Results, Aggregate Report, View Result in Table и View Result Tree.

Последняя настройка перед запуском — указать количество пользователей (Number of Threads) и количество итераций (Loop Count) нужно, нажав на Thread Group и установив соответствующие параметры.

Все готово. Запускаем тест, нажатием зеленого треугольника на верхней панели и открываем любой из элементов просмотра — перед нами статистика онлайн. Поскольку мы установили Loop Count — Forever, нажмем Stop после тестирования. Теперь по порядку о каждом элементе просмотра.

Graph Results отобразит результат в виде графика:

Значения предоставлены в миллисекундах.
Data — время отклика каждой отдельной единицы данных т.е. каждого проверенного url.
Average — усредненное время отклика, объективный график изменения нагрузки.
Median — значение медианы (используется в статистике, я этими данными не пользуюсь).
Deviation — погрешность, стандартное отклонение.
Throughput — пропускная способность выполняемых запросов.

Для работы достаточно значений Average и Throughput, которые отобразят нагрузку на веб-сервер и пропускную способность запросов. По графику выше видно, что время отклика примерно 200мс и не растет, то есть, сервер нормально выдерживает нагрузку в 3 виртуальных пользователя. А вот что получится, если их будет 30:

Время отклика значительно увеличивается, чем выше пропускная способность запросов (меньше миллисекунд), тем больше времени требуется серверу для обработки.

Кстати говоря, в то время, когда запущен тест, сайт действительно ложится, поэтому не следует проверять на нагрузку сторонние интернет-ресурсы, так как нас могут принять за ддосеров.

Aggregate Report отобразит статистику по каждому индивидуальному url отдельно.

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

View Result in Table отобразит результат в виде таблицы, здесь указано время, а также статус (успешно/не успешно).

В нижней строке ошибка. Почему именно она возникла, можно проверить в View Result Tree. Зайдем туда и найдем эту строку. Теперь видим причину ошибки.

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

Давайте представим, что Вы — единственный тестировщик на проекте, а то и во всей компании. Компания подписала контракт на разработку продукта, в котором очень важна производительность, а у Вас нет ни малейшего представления о том, с чего начать. Инструментов представлено большое количество, и выбрать какой-либо не так уж просто. Сейчас я предлагаю ознакомиться с Apache JMeter и запустить первый тест за 10 простых шагов. Предварительно нужно убедиться что установлена Java 8 или Java 9 на устройстве, с которого будут запускаться тесты.

2. Распаковываем архив. Путь к распакованной папке не должен содержать кириллицу или пробелы. Открываем распакованную папку, заходим в папку /bin, там находим сам JMeter (jmeter.bat для Windows
jmeter.sh для Unix) и запускаем его. В результате будет представлен такой интерфейс:

3. Далее нам нужно добавить пользователей, которые будут ходить на страничку. Для этого снова выбираем тест план правым кликом и далее следуем в /Add/Threads (Users)/Thread Group. В итоге, в тест плане появляется следующий элемент:

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

6. Тест нужно сохранить в папку /bin (там же, где лежит сам JMeter), далее, запустить терминал/командную строку и перейти в папку /bin, из которой на втором шаге запускали JMeter. Графическую оболочку лучше закрыть перед запуском теста. Запуск теста осуществляется командой:

jmeter -n -t test_name.jmx -l log.jtl (Windows)
sh jmeter.sh -n -t test_name.jmx -l log.jtl (Unix)

В примерах команд выше test_name.jmx — имя сохранённого теста, а log.jtl — имя файла, в который будут сохранены результаты теста. Ключ -n нужен для запуска инструмента в режиме без интерфейса (чтобы повысить производительность), ключ -t указывается перед именем сохраненного файла с тестом, ключ -l указывается перед именем файла, который будет создан в ходе прохождения теста и содержать отчёт.

7. Запускаем тест и ждём его завершения.

8. Далее, можно запустить JMeter командой jmeter (Windows) или sh jmeter.sh (Unix) отсюда же, из терминала/командной строки, или по старинке из папки /bin. После запуска нужно открыть сохранённый тест (в моём случае это doodles_test.jmx) и для него добавить отчёты. Самый простой отчёт — Summary Report, который добавляется через правый клик по Test Plan и, далее, Add/Listener/Summary Report. Listener’ы можно добавлять и в ходе настройки теста. Итак, Summary Report выглядит следующим образом:

9. Чтобы посмотреть результаты теста, нужно нажать Browse…, найти файлик с логами в формате *.jtl, который был прописан в шаге 6, и открыть его. В результате будет следующее:

10. Что можно понять из данного отчёта?

Было сделано 20 запросов (Samples) по указанному в конфиге адресу (10 пользователей по 2 раза каждый)
Среднее время ответа составило чуть меньше чем 1,1 секунды (Average); минимальное время ответа чуть менее чем 0,7 секунды (Min); максимальное время ответа чуть менее чем 1,5 секунды (Max).
В секунду проходило 6,4 запроса (Throughput).
Std Dev — показатель стандартного отклонения. Насколько я знаю, им мало кто пользуется, но, раз уж он есть, то… Этот показатель позволяет оценить насколько сильно значения из выборки (результата тестового прогона) отличаются от рассчитанного среднего значения.
Error %—количество ошибок в процентах, которые вернул сервер
Received и Sent KB/sec — количество полученных и отправленных данных
Avg.Bytes — среднее количество полученных данных

Заключение: В данной статье я постарался описать, пожалуй, один из самых простых способов начала работы с Apache JMeter. Причина проста — когда-то мне самому нужна была наглядная пошаговая инструкция для пробного запуска моего первого нагрузочного теста. Конечно, можно (и нужно!) изучать документацию по JMeter, смотреть видео инструкции, собирать информацию по форумам, но на это требуется немалое количество времени, которое у тестировщиков, зачастую, в дефиците :)

Цель этой статьи — научить вас выполнять нагрузочное тестирование и измерение производительности Restful API при помощи JMeter до и после развёртывания, используя подход с конфигурированием. В этот тест мы также добавим сравнение характеристик производительности по конкретным бенчмаркам. В итоге вы сможете моделировать нагрузку различных сценариев и вывод данных производительности несколькими способами, включая CSV и HTML отчёты.

Требования: Java 8 или Java 9 для Apache JMeter 5.1.1.

Для начала вам нужно загрузить JMe t er с сайта Apache Jmeter. После загрузки zip-файла извлеките его в директорию, где будете с ним работать. Затем в распакованной директории откройте папку /bin и запустите исполняемый Jar-файл. Откроется Apache JMeter с GUI.

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

Группы потоков;
Логические контроллеры;
Таймеры;
Пре- и постпроцессоры;
Элементы конфигурации;
т.д.

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

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

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

Конфигурационный файл CSV с разными конечными точками

Когда мы создадим CSV файл, нам понадобится настроить элемент конфигурации “CSV Data Set Config” в группе потоков, чтобы получать из CSV файлов следующие параметры:

testID (ID теста);
label (метка);
serverAddress (адрес сервера);
path (путь);
method (метод);
expectedCode (ожидаемый код);
payload (полезный данные).

В процессе настройки этого элемента конфигурации нужно указать путь к CSV файлу вместе с именами переменных согласно заданным в CSV файле колонкам, чтобы далее использовать всё это в подходящем месте.

Так как в конфигурации CSV у нас есть несколько конечных точек, нам нужно установить ‘Transaction Controller’ (Контроллер транзакций) для выполнения всех их последовательно, согласно заданному в CSV файле порядку. При этом мы можем использовать динамическое имя контроллера, как вы видите на изображении ниже. Имя устанавливается на основе определённых пользователем переменных, извлечённых из CSV файла (т.е. $ — $/($ ) = Test1-Load Test of Rest API

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

Это особая форма группа потоков, используемая для совершения нужных действий после завершения выполнения обычной группы потоков. Поведение потоков, указанных под Teardown Thread Group не отличается от стандартного.

Здесь я использую эту группу потоков для генерации HTML отчёта, применив сэмплер Beanshell после выполнения всех тестов. Более того, вы можете использовать её для отправки результата по e-mail с помощью сэмплера SMTP.

Генерирует HTML отчёт через Beanshell Sampler

Beanshell является одним из наиболее продвинутых встроенных компонентов JMeter. Он поддерживает синтаксис Java и расширяет его такими скриптовыми возможностями, как слабые типы, команды и замыкания методов. Здесь я использую Beanshell для генерации HTML отчёта, выполняя команды cmd. Эти команды содержат URL-адреса директорий, поступающие из файла конфигурации CSV, что даёт возможность прочитать результаты CSV и разместить HTML отчёт. Помимо этого, для истории скрипт создаёт сжатый файл HTML отчёта с текущей временной меткой.

Слушатель (Listener)— это компонент, показывающий результаты сэмплов. Результаты могут быть показаны в виде дерева, таблиц, графиков или просто записаны в файл журнала. Для просмотра содержимого ответа от любого заданного сэмплера добавьте слушателя “View Results Tree” или “Summary Report”, чтобы просмотреть результат внутри плана теста, либо “Simple Data Writer” для записи результатов в CSV файл.

Теперь, когда мы всё настроили как надо, пришло время запускать нагрузочный тест. Для этого нам нужно переконфигурировать элемент Thread Group в Test Plan так, чтобы он имел несколько свойств, относящихся к Thread. Кликните по Thread Group и добавьте в неё перечисленные ниже свойства. Т.к. мы осуществляем нагрузочное тестирование, нам следует предоставить тяжёлую нагрузку на конечную точку API. Изменение следующих параметров Thread Group позволяет JMeter правильно выполнить тест с нагрузкой.

Этими изменяемыми значениями являются три особо важных свойства, влияющих на тест:

Number of Threads (users): число пользователей, которых симулирует JMeter.

Ramp-Up Period (in seconds): общее количество времени, в течение которого JMeter будет распределять запуск всех потоков.

Loop Count: число выполнений теста.

Сохранив план теста, вы можете запустить его из консоли, кликнув по кнопке Play. После запуска вы сможете увидеть мгновенные результаты теста в добавленных слушателях или ознакомиться с ними позже в HTML отчёте. Однако в целях повышения производительности рекомендуется запускать план теста из командной строки, а не из режима GUI.

Читайте также: