10 шагов для запуска тестирования производительности с Apache JMeter.
Давайте представим, что Вы — единственный тестировщик на проекте, а то и во всей компании. Компания подписала контракт на разработку продукта, в котором очень важна производительность, а у Вас нет ни малейшего представления о том, с чего начать. Инструментов представлено большое количество, и выбрать какой-либо не так уж просто. Сейчас я предлагаю ознакомиться с Apache JMeter и запустить первый тест за 10 простых шагов. Предварительно нужно убедиться что установлена Java 8 или Java 9 на устройстве, с которого будут запускаться тесты.
- Скачиваем JMeter с сайта jmeter.apache.org в нужном формате
2. Распаковываем архив. Путь к распакованной папке не должен содержать кириллицу или пробелы. Открываем распакованную папку, заходим в папку /bin, там находим сам JMeter (jmeter.bat для Windows
jmeter.sh для Unix) и запускаем его. В результате будет представлен такой интерфейс:
3. Далее нам нужно добавить пользователей, которые будут ходить на страничку. Для этого снова выбираем тест план правым кликом и далее следуем в /Add/Threads (Users)/Thread Group. В итоге, в тест плане появляется следующий элемент:
- Number of Threads — число пользователей, которые будут обращаться по запросу, указанному в HTTP Request Defaults.
- Ramp-Up Period — время, в течение которого будут прибавляться юзеры. Позволяет делать плавный и прогнозируемый старт.
- Loop Count — количество итераций. На скриншоте выше значение равно 1, то есть каждый пользователь сделает всего 1 запрос.
Дополнение: Можно выставить базовые параметры, указанные выше на любые значения, которые хочется испытать, но для начала рекомендую обойтись небольшими величинами, например, 10 пользователей и пару циклов. Выставление огромного количества пользователей в одном треде может проглотить все мощности вашего устройства и оно просто перезагрузится 🙂
4. Для запуска теста нужно указать инструменту адрес сервера, который будет подвержен нагрузке с типом запроса. Это делается через правый клик по уже добавленному Thread Group и выбор Add/Sampler/HTTP Request
5. После добавления элемента можно указывать адрес сервера. Прежде чем ходить на чьи-то реальные/тестовые серверы и наводить панику на команды разработки и поддержки, стоит попробовать свои силы на простейшем примере поисковой системы. В данном случае я предлагаю сходить на google.com, а точнее, на страницу, так называемого, “Мне повезёт!” (https://www.google.com/doodles/). Для этого в протоколе указываем https, в адресе сервера google.com, а в пути расположение страницы /doodles/, ну и не забываем про тип запроса GET .
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, смотреть видео инструкции, собирать информацию по форумам, но на это требуется немалое количество времени, которое у тестировщиков, зачастую, в дефиците 🙂
JMeter настройка Thread Group, что означает Rump-Up period?

Всем привет.
Осваиваю JMeter, и в процессе курения мануала и запуска пробных тестов возникло недопонимание одного момента.
У нас есть параметры:
Number of Threads — это количество юзеров которые будут заходить на сайт
Rump-Up period — это период через который будут запускаться наши юзеры
Loop Count — это кол-во циклов исполнения юзерами действий в Thread Group
Для тестирования были взяты данные из потолка
Number of Threads = 10
Rump-Up period =15 sec
Loop Count = 100
Далее то что я не до конца понял:
У нас «зайдут» на сайт 10 юзеров в течении 15 секунд и это все повторится 100 раз и в итоге у нас отправится 1000 запросов?
Т.е. время прохождения скрипта должно занять 1500 секунд, но проходит 150 секунд.
Не могу понять что и зачем начинает запускаться и сколько это занимает времени.
- Вопрос задан более трёх лет назад
- 7873 просмотра
1 комментарий
Оценить 1 комментарий
По этому профилю за первые 15 секунд (Rump-Up period ) запустится 10 потоков (Number of Threads). И точно засчитается выполнение одной итерации теста, останется каждому потоку выполнить максимум ещё 99 итераций (Loop Count — 1).
Если так случиться, что каждый поток упеет выполнить 99 итераций раньше, чем за 300 сек (~285-300), то тест закончится в момент выполнения последним активным потоком своей 100-й итерации.
Если же 100 итераций не получится успеть выполнить за 300 сек, то тест просто прервётся. Сколько итераций успели сделать, столько и сделано.
Таким образом, тест будет не большее чем 300 секунд выполняться.
Используя 10 подключение (начиная с 15-й секунды).
На первой секунде будет только 1 подключение или 2.
На 7-й, примерно 5 подключений.
На 15-й запустятся все 10 потоков.
В этом постепенном подъеме и смысл Rump-Up period
Решения вопроса 1
ashipovalov @ashipovalov
У вас настроен и loop count и расписание. Не надо так. Вообще же, у вас в течении 15 секунд на сайте окажется 10 виртуальных пользователей и в течении всего времени каждый их них (включая Rump-up период) 100 раз выполнит ваш запрос. Вот и вся магия. Со временем выполнения скрипта это практически никак не коррелируется, все зависит от того как быстро приходят ответы
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ответы на вопрос 1
Тестировщик
Как можно использовать эти параметры.
Пусть нужна интенсивность выполнения сценария «Аутентификация, Создание и скачивание документа» равная 8 в сек. И чтобы тест выполнялся в таком режиме 30 минут или 1800 сек.
То есть, нужно, чтобы за 1 секунду запускалось выполнение 8 потоков (virtual user / thread).
Значит за 10 000 секунд должно запуститься 80 000 потоков.
Это если каждый поток будет делать одну итерацию теста.
- Users — 80 000
- Rump-Up — 10 000
- Loop Count — 1
- Duration — 1800
- Startup Delay — 0
- Users — 40 000
- Rump-Up — 10 000
- Loop Count — 2
- Duration — 1800
- Startup Delay — 0
- Users — 10 000
- Rump-Up — 10 000
- Loop Count — 8
- Duration — 1800
- Startup Delay — 0
- Users — 4000
- Rump-Up — 4000
- Loop Count — 8
- Duration — 1800
- Startup Delay — 0
5) Тестирование производительности
Производительность тестирование имеет решающее значение для определения того, что веб — приложение , испытуемый будет удовлетворять высокие нагрузки требований. Он может быть использован для анализа общей производительности сервера при большой нагрузке.
Инструмент тестирования Apache JMeter предлагает следующие преимущества в тестировании производительности
- JMeter можно использовать для тестирования производительности как статических ресурсов, таких как JavaScript и HTML, так и динамических ресурсов, таких как JSP, сервлеты и AJAX.
- JMeter может обнаружить максимальное количество одновременных пользователей, которое может обработать ваш сайт
- JMeter предоставляет различные графические анализы отчетов о производительности.
Тестирование производительности JMeter включает в себя:
- Нагрузочное тестирование: моделирование ожидаемого использования путем симуляции многопользовательского доступа к веб-сервисам одновременно.
- Стресс- тестирование. Каждый веб-сервер имеет максимальную нагрузочную способность. Когда нагрузка выходит за пределы предела, веб-сервер начинает медленно реагировать и выдавать ошибки. Цель стресс-тестирования — найти максимальную нагрузку, которую может выдержать веб-сервер.
На рисунке ниже показано, как JMeter load Testing моделирует большую нагрузку:
Создать план тестирования производительности в JMeter
В этом руководстве мы проводим анализ производительности Google.com для 1000 пользователей.
Перед тестированием производительности целевого веб-приложения мы должны определить
- Нормальная нагрузка : среднее количество пользователей, посещающих ваш сайт
- Heavy Load : максимальное количество пользователей, посещающих ваш сайт
- Какова ваша цель в этом тесте?
Вот дорожная карта этого практического примера
Шаг 1) Добавить группу тем
- Запустите JMeter
- Выберите план тестирования на дереве
- Добавить группу тем
Щелкните правой кнопкой мыши «План тестирования» и добавьте новую группу потоков: Добавить -> Темы (Пользователи) -> Группа потоков
На панели управления «Группа потоков» введите «Свойства потока» следующим образом:

- Количество потоков : 100 (Количество пользователей, подключающихся к целевому сайту: 100)
- Количество циклов : 10 (Количество времени для выполнения тестирования)
- Период разгона : 100
Количество потоков и количество циклов различны.
Ramp-Up Period сообщает JMeter, как долго откладывать перед запуском следующего пользователя. Например, если у нас 100 пользователей и 100-секундный период разгона, то задержка между начинающими пользователями составит 1 секунду (100 секунд / 100 пользователей).
Шаг 2) Добавление элементов JMeter
Теперь мы определим, какие элементы JMeter в этом тесте. Элементы
HTTP-запрос по умолчанию
Этот элемент можно добавить, щелкнув правой кнопкой мыши на группе потоков и выбрав: Добавить -> Элемент конфигурации -> Параметры HTTP-запроса по умолчанию.
В панели управления по умолчанию HTTP-запроса введите тестируемое имя веб-сайта ( http://www.google.com ).
HTTP-запрос
Щелкните правой кнопкой мыши группу потоков и выберите: Добавить -> Выборка -> Запрос HTTP .
В панели управления HTTP-запросами поле «Путь» указывает, какой URL-запрос вы хотите отправить на сервер Google.
Например, если вы введете « календарь » в поле «Путь». JMeter создаст запрос URL http://www.google.com/calendar на сервер Google
Если вы оставите поле Path пустым, JMeter создаст запрос URL http://www.google.com на сервер Google.
В этом тесте вы оставите поле Path пустым, чтобы JMeter создавал запрос URL http://www.google.com на сервер Google.
Шаг 3) Добавление графического результата
JMeter может показывать результаты теста в формате Graph.
Щелкните правой кнопкой мыши План тестирования, Добавить -> Слушатель -> Результаты графика.
Шаг 4) Запустите тест и получите результат теста
Нажмите кнопку «Выполнить» (Ctrl + R) на панели инструментов, чтобы начать процесс тестирования программного обеспечения. Вы увидите результаты теста на графике в режиме реального времени.
На рисунке ниже представлен график плана тестирования, где мы смоделировали 100 пользователей, которые заходили на сайт www.google.com .
Внизу рисунка есть следующая статистика, представленная в цветах:
- Черный: общее количество отправленных текущих образцов.
- Синий : текущее среднее всех отправленных образцов.
- Красный : текущее стандартное отклонение.
- Зеленый : пропускная способность, которая представляет количество запросов в минуту, обработанных сервером
Давайте проанализируем производительность сервера Google на рисунке ниже.
Чтобы проанализировать производительность тестируемого веб-сервера, необходимо сосредоточиться на 2 параметрах
- пропускная способность
- Отклонение
Пропускная способность является наиболее важным параметром. Он представляет способность сервера справляться с большой нагрузкой. Чем выше пропускная способность, тем выше производительность сервера.
В этом тесте пропускная способность сервера Google составляет 1 491,193 в минуту. Это означает, что сервер Google может обрабатывать 1 491 193 запроса в минуту. Это значение довольно высокое, поэтому мы можем заключить, что сервер Google имеет хорошую производительность
Отклонение отображается красным цветом — это указывает на отклонение от среднего значения . Чем меньше, тем лучше .
Давайте сравним производительность сервера Google с другими веб-серверами. Это результат теста производительности сайта http://www.yahoo.com/ (Вы можете выбрать другие сайты)
Пропускная способность тестируемого веб-сайта http://www.yahoo.com составляет 867,326 / мин. Это означает, что этот сервер обрабатывает 867,326 запросов в минуту, что ниже, чем у Google.
Отклонение составляет 2689, намного выше, чем Google (577). Таким образом, мы можем определить производительность этого веб-сайта меньше, чем на сервере Google.
ПРИМЕЧАНИЕ. Приведенные выше значения зависят от нескольких факторов, таких как текущая нагрузка на сервер в Google, скорость вашего интернета, мощность вашего процессора и т. Д. Следовательно, очень маловероятно, что вы получите те же результаты, что и выше. Так что не паникуйте!
Поиск проблемы:
Если вы столкнулись с проблемой во время выполнения вышеуказанного сценария … выполните следующее
- Проверьте, подключены ли вы к Интернету через прокси. Если да, удалите прокси.
- Откройте новый экземпляр Jmeter
- Откройте PerformanceTestPlan.jmx в Jmeter
- Двойной щелчок по группе нитей -> Результат графика
- Запустить тест
Нагрузочное тестирование базы данных с помощью Apache JMeter
Нагрузочное тестирование используется для проверки отказоустойчивости приложений, использующих базу данных, наличие проблем с производительностью и масштабируемостью при различном уровне нагрузки.

Необходимые ресурсы
- Установите Java Development Kit.
- Установите Apache JMeter.
Пример использования
Выполним нагрузочное тестирование базы данных с помощью Apache JMeter. Чтобы измерить ее производительность, используем драйвер MySQL JDBC.
План тестирования базы данных
План тестирования описывает последовательность шагов, которые должен выполнить JMeter. Для его составления необходимы следующие элементы:
- Группа потоков.
- Запрос JDBC.
- Сводный отчет.
Добавление пользователей
Группа потоков предоставляет подробную информацию о количестве пользователей, частоте и количестве запросов, которые будут отправлены пользователями во время тестирования.
Чтобы создать группу потоков, выполните следующие действия:
- В левой панели кликните правой кнопкой мыши по Test Plan .
- Выберите Add → Threads (Users) → Thread Group.

- Укажите имя группы потоков – « JDBC Users ».
- Нажмите кнопку Add и измените значения свойств, используемые по умолчанию, следующим образом:
- No. of Threads (users): 10.
- Ramp-Up Period (in seconds): 100.
- Loop Count: 10.

Примечание. Ramp-Up Period указывает время, необходимое для увеличения количества потоков до максимального значения.
Мы используем 10 потоков, а период разгона составляет 100 секунд. Каждый новый поток запускается через 10 секунд после начала предыдущего. Таким образом, запрос будет выполнен 10 (потоков) * 10 (циклов) = 100 раз. Аналогично, для 10 таблиц общее количество экземпляров составляет 100.
Добавление запросов JDBC
Чтобы добавить запрос JDBC, выполните следующие действия:
- В левой панели кликните правой кнопкой мыши по Thread Group .
- Выберите Add → Config Element → JDBC Connection Configuration .
- Настройте следующие параметры:
- Variable Name: myDatabase
Примечание . Это имя должно быть уникальным, так как оно используется JDBC Sampler для идентификации используемой конфигурации.
- Database URL: jdbc:mysql://ipOfTheServer:3306/cloud
- JDBC Driver class: mysql.jdbc.Driver.
- Username: имя пользователя базы данных.

Добавление сэмплера
Чтобы добавить сэмплер, выполните следующие действия:
- В левой панели кликните правой кнопкой мыши по Thread Group .
- Выберите Add → Sampler → JDBC Request .
- Укажите Variable Name: «myDatabase».
- Введите запрос в поле SQL Query.

Добавление обработчика для просмотра и сохранения результатов теста
Чтобы просмотреть результаты теста, выполните следующие действия:
- В левой панели кликните правой кнопкой мыши по Thread Group .
- Выберите Add → Listener → View Results Tree/Summary Report/Graph Results .
- Сохраните план тестирования и нажмите Run (Start или «Ctrl + R»), чтобы запустить тест.
- Все результаты теста будут сохранены в обработчике.
Просмотр результатов теста:
Результаты можно просмотреть в древовидном формате:

В табличном представлении:


А также в виде диаграмм:

Показатели эффективности
С помощью JMeter можно увидеть различные показатели производительности.
Пропускная способность
Общее количество запросов в единицу времени, отправленных на сервер во время теста.
В нашем случае пропускная способность составляет 61,566 / в минуту. Высокое значение пропускной способности указывает на хорошую производительность.
Задержка
Задержка при передаче сообщения. Меньшее значение задержки указывает на большой объем отправляемой / получаемой информации. В нашем примере задержка для первого потока составляет 24446.
Минимальное / максимальное время загрузки / время отклика / время выборки
Разница между временем отправки запроса и временем получения ответа. Время отклика всегда больше или равно задержке.
В нашем примере для всех запросов время отклика> = задержка.
Линия 90% (90-ый процентиль)
Пороговое значение, ниже которого попадает 90% экземпляров. Чтобы вычислить этот показатель, отсортируйте экземпляры транзакций по их значению и удалите верхние 10% экземпляров. Самое большое из оставшихся значений – это линия 90 %.
Ошибки
Общий процент ошибок, найденных в экземпляре запроса. Значение 0,00% указывает на то, что все запросы выполнены успешно и производительность хорошая.
Стандартное отклонение
Более низкое значение стандартного отклонения указывает на большую согласованность данных. Стандартное отклонение должно быть меньше или равно половине среднего времени для метки. Если значение больше, это указывает на недопустимое значение. В нашем случае это 2881.
Минимальное время
Минимальное время, необходимое для отправки запросов. Общее время равно минимальному времени для всех образцов. В нашем случае это 0 мс.
Максимальное время
Максимальное время, необходимое для отправки запросов. Общее время равно максимальному времени для всех образцов. В нашем случае это 23 234 мс.
Среднее время
Среднее время ответа на запрос
КБ / сек
Измерение пропускной способности в килобайтах в секунду. В нашем случае это 0.
Сэмплеры
Общее количество запросов, отправленных на сервер. В нашем случае это 100.
Заключение
В этой статье мы рассмотрели тестирование производительности базы данных с помощью JMeter путем увеличения пользовательской нагрузки.
Полученные в ходе тестирования показатели могут использоваться в Performance Tuning Engineer для выявления слабых мест производительности.
