2021 руководство по jmeter: нагрузка и производительность тестирование учебник

Prerequisites

In order to follow this tutorial, you will need to have a computer that you can run JMeter on, and a web server to load test against. Do not run these tests against your production servers unless you know they can handle the load, or you may negatively impact your server’s performance.

You may adapt the tests in this tutorial to any of your own web applications. The web server that we are testing against as an example is a 1 CPU / 512 MB VPS running WordPress on a LEMP Stack, in the NYC2 DigitalOcean Datacenter. The JMeter computer is running in the DigitalOcean office in NYC (which is related to the latency of our tests).

Please note that the JMeter test results can be skewed by a variety of factors, including the system resources (CPU and RAM) available to JMeter and the network between JMeter and the web server being tested. The size of the load that JMeter can generate without skewing the results can be increased by running the tests in the non-graphical mode or by distributing the load generation to multiple JMeter servers.

Занятие 3. Нагрузка

Модуль 3.1. Требования к производительности

Требования к скорости.
Требования к надёжности.
Требования к ресурсоёмкости.
Требования к окружению.
Динамические и статические требования.
Средние значения и аномалии.

Модуль 3.2. Цели тестирования и профили нагрузки

Анализ требований и определение целей тестирования
Что такое модель нагрузки и как она соотносится с целями тестирования.
Типовые модели нагрузки: на обнаружение какого рода проблем они нацелены.

Модуль 3.3. Реализация типовых моделей нагрузки в JMeter

Постоянная нагрузка
Возрастающая нагрузка
Пиковые нагрузки

Модуль 3.4. Выполнение тестов

Калибровка сценариев.
Функциональное тестирование в параллельном режиме.
Стабилизация показателей и определение базы (baseline).
Запуск с различными вариациями.
Что делать во то время, пока выполняются тесты?

Модуль 3.5. Тестирование клиентской производительности

Встроенные в браузеры средств.
Облачные сервисы.

Занятие 2. Сценарии

Модуль 2.1. Протоколы взаимодействия с тестируемой системой

Сетевые протоколы.
Удалённые программные интерфейсы (Remote API).
API, за которыми скрывается что угодно.

Модуль 2.2. Проектирование сценариев

Моделирование поведения пользователей.
Что считать – пользователей или запросы?
Задержки между запросами.
Управление логикой сценария.
Как правильно делать login и logout.
Создание сценариев из переиспользуемых модулей.

Модуль 2.3. Работа с данными в JMeter

Глобальные параметры (адрес тестового стенда и т.п.)
Автоподстановка параметров во время записи сценариев.
Генерация случайных данных.
Чтение данных из внешних файлов.

Модуль 2.4. Корреляция данных в JMeter

Выявление данных, требующих корреляции.
Экстракторы: регулярные выражения, XPath, CSS Selectors.

Модуль 2.5. Проверки (assertions)

Функциональные проверки
Контроль времени отклика
Таймауты

Создание нагрузочного теста

Запустите JMeter. На экране появится графический интерфейс; откройте Test Plan. На данный момент не существует ни одного плана.

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

Добавление группы потоков

Для начала нужно добавить в план группу потоков (Thread Group):

Щелкните правой кнопкой по Test Plan
Выберите Add >
Найдите и выберите Threads (Users) >
Выберите Thread Group

Группы потоков имеют три особенно важных параметра, которые влияют на тестирование нагрузки:

Number of Threads (users): Количество потоков (пользователей), которое будет эмулировать JMeter; установите значение 50.
Ramp-Up Period (in seconds): Продолжительность тестирования в секундах. Установите значение 10
Loop Count: Количество тестов. Установите 1.

Добавление настроек HTTP

Элемент HTTP Request Defaults используется для установки стандартных значений HTTP-запросов в данном плане тестирования. Добавьте HTTP Request Defaults для Thread Group:

Кликните правой кнопкой на Thread Group.
Выберите Add.
Затем выберите Config Element >.
Кликните HTTP Request Defaults.

На экране появятся настройки для HTTP Request Defaults. В разделе Web Server найдите поле Server Name or IP и укажите в нём имя или IP-адрес веб-сервера, который нужно протестировать. Установленный здесь сервер становится сервером по умолчанию для остальных элементов этой группы потоков.

Добавление HTTP Cookie Manager

Если сервер использует cookie-файлы, можно настроить их поддержку. Для этого нужно добавить Thread Group элемент HTTP Cookie Manager:

Кликните правой кнопкой на Thread Group.
Выберите Add.
Затем выберите Config Element >.
Кликните HTTP Cookie Manager

Добавление сэмплера запросов HTTP

За настройки сэмплера запросов HTTP отвечает компонент HTTP Request, представляющий запросы к странице для каждого потока.

Кликните правой кнопкой на Thread Group.
Выберите Add.
Затем выберите Sampler >.
Кликните HTTP Request.

В появившемся окне настроек найдите раздел HTTP Request, в Path укажите объект, которому все пользователи должны отправить запрос. Установите /, чтобы все пользователи отправили запросы к домашней странице

Обратите внимание: сервер указывать не нужно, поскольку он уже указан в HTTP Request Defaults

Примечание: Чтобы добавить в тест больше HTTP Requests, повторите инструкции данного раздела.

Настройка просмотра результатов

Для вывода результатов нагрузочного тестирования используются плагины JMeter под названием listeners. Существует множество доступных плагинов. Используйте таблицу, поскольку её проще читать.

Кликните правой кнопкой на Thread Group.
Выберите Add.
Затем выберите Listener >.
Кликните View Results in Table.

Также можно задать Filename, чтобы направить вывод в CSV-файл.

Step 2) Adding JMeter elements

Now we determine what JMeter elements in this test. The elements are

HTTP request Default

Add Config Element HTTP Request Defaults.

In the HTTP Request Defaults control panel, enter the Website name under test (http://www.google.com)

HTTP Request

Right-click on Thread Group and select: Add -> Sampler -> HTTP Request.

In HTTP Request Control Panel, the Path field indicates which URL request you want to send to Google server.

For example, if you enter “calendar” in Path field. JMeter will create the URL request http://www.google.com/calendar to Google server

If you keep the Path field blank JMeter will create the URL request http://www.google.com to Google server.

In this test, you keep the Path field blank to make JMeter create the URL request http://www.google.com to Google server.

13.5 Using a different sample sender¶

Listeners in the test plan send their results back to the client JMeter which writes the results to the specified files
By default, samples are sent back synchronously as they are generated.
This can affect the maximum throughput of the server test; the sample result has to be sent back before the thread can
continue.
There are some JMeter properties that can be set to alter this behaviour.

mode

sample sending mode — default is StrippedBatch since 2.9. This should be set on the client node.

Standard

send samples synchronously as soon as they are generated

Hold

hold samples in an array until the end of a run. This may use a lot of memory on the server and is discouraged.

DiskStore

store samples in a disk file (under java.io.temp) until the end of a run.
The serialised data file is deleted on JVM exit.

StrippedDiskStore

remove responseData from successful samples, and use DiskStore sender to send them.

Batch

send saved samples when either the count (num_sample_threshold) or time (time_threshold) exceeds a threshold,
at which point the samples are sent synchronously.
The thresholds can be configured on the server using the following properties:

num_sample_threshold: number of samples to accumulate, default 100
time_threshold: time threshold, default 60000 ms = 60 seconds

See also the Asynch mode, described below.

Statistical

send a summary sample when either the count or time exceeds a threshold.
The samples are summarised by thread group name and sample label.
The following fields are accumulated:

elapsed time
latency
bytes
sample count
error count

Other fields that vary between samples are lost.

Stripped

remove responseData from successful samples

StrippedBatch

remove responseData from successful samples, and use Batch sender to send them.

Asynch

samples are temporarily stored in a local queue. A separate worker thread sends the samples.
This allows the test thread to continue without waiting for the result to be sent back to the client.
However, if samples are being created faster than they can be sent, the queue will eventually fill up,
and the sampler thread will block until some samples can be drained from the queue.
This mode is useful for smoothing out peaks in sample generation.
The queue size can be adjusted by setting the JMeter property
asynch.batch.queue.size (default 100) on the server node.

StrippedAsynch

remove responseData from successful samples, and use Async sender to send them.

Custom implementation

set the mode parameter to your custom sample sender class name.
This must implement the interface SampleSender and have a constructor which takes a single
parameter of type RemoteSampleListener.

Stripped mode family strips responseData so this means that some Elements that rely
on the previous responseData being available will not work.
This is not really a problem as there is always a more efficient way to implement this feature.

The following properties apply to the Batch and Statistical modes:

Увеличение нагрузки

Попробуйте выполнить такой же тест, увеличив количество потоков до 80 за 10 секунд. Откройте Thread Group в левой панели и измените Number of Threads (users) до 80. Затем кликните View Results in Table и Start.

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

Для этого используйте команду:

Если на данный момент сервер не посещают другие пользователи, резултат будет примерно таким:

Как видите, использование Cpu(s) us очень низкое, а id превышает 99%.

После этого снова запустите тест JMeter и вернитесь в SSH-сессию на сервере. Посл этого использование ресурсов возрастёт:

В данном примере пользователи используют 94% CPU, а система (sy) 4.7%.

В данном случае памяти хватает, а значит, причиной снижения производительности является нехватка ресурсов процессора.

Чтобы оптимизировать работу сервера для поддержки 80 пользователей за 10 секунд, нужно либо увеличить CPU, либо настроить сервер для использования меньшего количества CPU.

Попробуйте изменить количество потоков и выяснить, какое именно количество становится критичным; в данном случае сервер может без сбоев поддерживать 72 пользователя за 10 секунд.

2.5 Running a Test Plan¶

To run your test plan, choose «Start» (Control + r)
from the «Run» menu item.
When JMeter is running, it shows a small green box at the right hand end of the section just under the menu bar.
You can also check the «Run» menu.
If «Start» is disabled, and «Stop» is enabled,
then JMeter is running your test plan (or, at least, it thinks it is).

The numbers to the left of the green box are the number of active threads / total number of threads.
These only apply to a locally run test; they do not include any threads started on remote systems when using client-server mode.

Using GUI mode as described here should only be used when debugging your Test Plan. To run the real load test, use CLI mode.

Профили нагрузки

Думайте о веб-сервисе в контексте тестирования производительности как о системе организации движения в городе. Люди хотят попасть из пункта А в пункт Б. Им нужно проехать через несколько улиц. Некоторые из них имеют 5 полос движения, другие — только одну. Одни позволяют двигаться со скоростью 130 км/ч, другие — 50 км/ч. В зависимости от времени может образоваться затор. Если есть узкое место, и машин немного, то, возможно, все будет работать как надо и заторов не будет. Но чем больше машин находится в дорожной системе, тем выше вероятность того, что кому-то придется ждать.

Дорожная система — это ваш веб-сервис. Узким местом может быть блокирующий вызов ресурса, например, транзакция базы данных при высоком уровне изоляции транзакций. Скорость движения — это скорость выполнения транзакции.

How to do load testing with JMeter?

В этом разделе мы создадим простой нагрузочный тест с использованием Apache JMeter. Вам следует выполнить следующие действия:

Step 1. Create new Thread Group

Чтобы начать нагрузочный тест, нам нужно создать новую группу потоков. Щелкните план тестирования правой кнопкой мыши и выберите Добавить> Потоки (пользователи)> Группа потоков. Здесь мы можем указать следующие параметры:

Количество потоков = 10 циклов ускорения = 1 количество циклов = 100

Step 2. Set up configuration

Следующим шагом является настройка конфигурации для нашего нагрузочного теста. Наш виртуальный api работает как локальный хост: 8800, поэтому мы должны сообщить JMeter, где его найти. Щелкните правой кнопкой мыши группу потоков и выберите Добавить> Элемент конфигурации> Запрос HTTP по умолчанию. Здесь мы добавляем:

Протокол = имя сервера http = порт локального хоста = 8800 путь = /

Step 3. Add HTTP Request

Теперь мы можем добавить семплер — в нашем случае HTTP-запрос. Мы заранее все определили на предыдущем шаге, поэтому здесь ничего добавлять не нужно. Хотя в более сложных тестах это, конечно, нужно уточнять. Оставьте пока все пустым.

Step 4. Create a listener

Наконец, добавьте слушателя — элемент, отображающий результаты. Перейдите в Добавить> Слушатель> Сводный отчет. Сводный отчет создает строку таблицы для каждого запроса с другим именем в тесте. Используя этот компонент, вы также можете сохранить данные в формате CSV.

Step 5. Run a test

Теперь вы можете запустить нагрузочный тест (не забудьте сохранить тест). Мы получили интерпретируемый лист данных:

Метка = имя сэмплера HTTP-запроса. Образец = среднее количество виртуальных пользователей на запрос = среднее время, необходимое для всех выборок для выполнения определенного тега. Мин. = Наименьшее время, необходимое для конкретной выборки тега. Макс = наибольшее время, затраченное на конкретный образец метки. St.Dev = набор исключений, которые отклоняются от среднего времени отклика образца. Ошибка = процент неудачных запросов для каждой метки. Пропускная способность = количество запросов, обработанных сервером в единицах времени (секунды, минуты, часы)

I recommend you to observe the documentation for or this post on understanding a summary report.

13.4 Using a different port¶

By default, JMeter uses the standard RMI port 1099. It is possible to change this. For this to work successfully,
all the following need to agree:

On the server, start rmiregistry using the new port number
On the server, start JMeter with the property server_port defined
On the client, update the remote_hosts property to include the new remote host:port settings

Since JMeter 2.1.1, the jmeter-server scripts provide support for changing the port.
For example, assume you want to use port 1664 (perhaps 1099 is already used).

C:\JMETER> SET SERVER_PORT=1664
C:\JMETER> JMETER-SERVER

$ SERVER_PORT=1664 jmeter-server

In both cases, the script starts rmiregistry on the specified port,
and then starts JMeter in server mode, having defined the «server_port» property.

Углубляемся в проблемы производительности

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

Подсчет количества запросов

ORM — это замечательно, но очень легко можно столкнуться с проблемой (n+1)-го числа. Это довольно легко обнаружить, если написать модульные тесты для этих частей и также проверить количество выполненных SQL-запросов.

Изменение архитектуры микросервисов

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

Измерение использования памяти

Когда я работал над задачами в области машинного обучения, иногда случалось, что мне нужно было перемножать большие матрицы в продакшн-системе. Чтобы облегчить себе задачу, я измерял пиковое использование памяти с помощью valgrind и визуализировал его с помощью kcachegrind или memory_profiler в мире Python. Эти инструменты называются «профилировщики памяти», и они могут показать всевозможные вещи, включая графики вызовов, как на изображении ниже:

Граф вызовов, построенный с помощью kcachegrind

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

Run the Basic Test Plan

Now that we have our basic test plan set up, let’s run it and see the results.

First, save the test plan by clicking on File then Save, then specify your desired file name. Then select on View Results in Table in the left pane, then click Run from the main menu then click Start (or just click the green Start arrow below the main menu). You should see the test results in the table as the test is run like:

Interpreting the Results

You will probably see that the Status of all the requests is “Success” (indicated by a green triangle with a checkmark in it). After that, the columns that you are probably most interest in are the Sample Time (ms) and Latency (not displayed in example) columns.

Latency: The number of milliseconds that elapsed between when JMeter sent the request and when an initial response was received
Sample Time: The number of milliseconds that the server took to fully serve the request (response + latency)

According to the table that was generated, the range of Sample Time was 128-164 ms. This is a reasonable response time for a basic homepage (which was about 55 KB). If your web application server is not struggling for resources, as demonstrated in the example, your Sample Time will be influenced primarily by geographical distance (which generally increases latency) and the size of the requested item (which increases transfer time). Your personal results will vary from the example.

So, our server survived our simulation of 50 users accessing our 55 KB WordPress homepage over 10 seconds (5 every second), with an acceptable response. Let’s see what happens when we increase the number of threads.

Пример использования

Выполним нагрузочное тестирование базы данных с помощью 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:имя пользователя базы данных.

Password: пароль.

Добавление сэмплера

Чтобы добавить сэмплер, выполните следующие действия:

В левой панели кликните правой кнопкой мыши по Thread Group.
Выберите Add→ Sampler → JDBC Request.
Укажите Variable Name:
Введите запрос в поле SQL Query.

«myDatabase».

Добавление обработчика для просмотра и сохранения результатов теста

Чтобы просмотреть результаты теста, выполните следующие действия:

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

Просмотр результатов теста:

Результаты можно просмотреть в древовидном формате:

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

В графическом:

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

Описание

«Младших тестировщиков производительности» не бывает. Зато бывают люди, которые начинают заниматься тестированием производительности.

(с) Скотт Барбер (aka The Perf Guy)

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

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

На тренинге мы будем учиться обращаться с этим оружием:

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

Для практических демонстраций и для выполнения домашних заданий будет использоваться инструмент JMeter.

1. Установка Apache.JMeter

Скачиваются два файла:

apache-jmeter-5.0.zip (zip)
apache-jmeter-5.0.zip.asc (pgp)

Zip-файл скачивается с ближайшего зеркала, а подпись скачивается с сервера Apache.

Можно оба файла скачать с сервера Apache, тогда проверка подписи особо не нужна. Также с сервера Apache берётся дистрибутив прежних версий, например, версии 3.1:

https://archive.apache.org/dist/jmeter/binaries/
apache-jmeter-5.0.zip

Архив нужно распаковать, например, в каталог:

D:\tools\apache-jmeter-5.0\

Установка завершена.

Перед запуском можно проверить целостность скачанного архива, а также установить java нужной версии.

Назначение каталогов и файлов:

bin — исполняемые файлы Apache.JMeter
- ApacheJMeter.jar — java-сборка Apache.JMeter
- heapdump.cmd, heapdump.sh
- jmeter.bat, jmeter.sh, jmeter
- jmeter-n.cmd
docs — документация
extras — дополнительные скрипты и утилиты
lib — библиотеки
licenses — лицензии
printable_docs — документация
LICENSE — лицензия Apache 2.0 на Apache.JMeter (перевод, описание)
NOTICE — примечание
README.md — описание, требования, инструкция по установке и сборке

. Проверка целостности скачанного архива (опционально)

Удобно использовать консоль git-клиента в Windows, так как по умолчанию в MinGW есть утилита gpg для проверки корректности подписи

Порядок проверки:

Проверить pgp-подпись с помощью утилиты gpg.
Если RSA ключ не был найден, то
1. скачать указанный ключ с сервера pgpkeys.mit.edu с помощью утилиты gpg.
2. проверить pgp-подпись с помощью утилиты gpg снова.

Если подпись корректна, то будет видна строчка «Good signature».

. Установка Java

Выдержка из файла README.md гласит, что нужна Java 8:

И рекомендуется установить JDK, а не просто JRE.

Утилита keytool нужна, чтобы Apache.JMeter мог перехватывать и расшифровывать трафик по протоколу HTTPS, работая в режиме прокси.

Рекомендация, что нужно именно JDK сомнительная, так как в JRE тоже есть утилита keytool:

C:\Program Files\Java\jre1.8.0_192\bin\keytool.exe

Считаю, что требование JDK для работы keytool — ошибка Apache.JMeter, которая уже исправлена, но в документации ещё не отражена:

https://bz.apache.org/bugzilla/show_bug.cgi?id=61026

Java (JRE) скачивается с сайта:

https://java.com/ru/download/manual.jsp
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html

Java (JDK), Java SE Development Kit 8, скачивается с сайта:

http://www.oracle.com/technetwork/java/javase/downloads/2133151
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

На текущий момент, актуальная версия 8 Update 192.

13.3 Tips¶

JMeter/RMI requires a connection from the client to the server. This will use the port you chose, default 1099.
JMeter/RMI also requires a reverse connection in order to return sample results from the server to the client.
These will use high-numbered ports.
These ports can be controlled by jmeter property called client.rmi.localport in jmeter.properties.
If this is non-zero, it will be used as the base for local port numbers for the client engine. At the moment JMeter will open
up to three ports beginning with the port defined in client.rmi.localport.
If there are any firewalls or other network filters between JMeter client and server,
you will need to make sure that they are set up to allow the connections through.
If necessary, use monitoring software to show what traffic is being generated.

If you’re running Suse Linux, these tips may help. The default installation may enable the firewall. In that case,
remote testing will not work properly. The following tips were contributed by Sergey Ten.

If you see connections refused, turn on debugging by passing the following options.

rmiregistry -J-Dsun.rmi.log.debug=true \
     -J-Dsun.rmi.server.exceptionTrace=true \
     -J-Dsun.rmi.loader.logLevel=verbose \
     -J-Dsun.rmi.dgc.logLevel=verbose \
     -J-Dsun.rmi.transport.logLevel=verbose \
     -J-Dsun.rmi.transport.tcp.logLevel=verbose \

Since JMeter 2.3.1, the RMI registry is started by the server; however the options can still be passed in from the JMeter command line.
For example: «jmeter -s -Dsun.rmi.loader.logLevel=verbose» (i.e. omit the -J prefixes).
Alternatively the properties can be defined in the system.properties file.

The solution to the problem is to remove the loopbacks 127.0.0.1 and 127.0.0.2 from /etc/hosts.
What happens is jmeter-server can’t connect to rmiregistry if 127.0.0.2 loopback is not available.
Use the following settings to fix the problem.

Replace

`dirname $0`/jmeter  -s "$@"

With

HOST="-Djava.rmi.server.hostname= \
      -Djava.security.policy=`dirname $0`/" \
`dirname $0`/jmeter $HOST -s "$@"

Also create a policy file and add line to /etc/hosts.

In order to better support SSH-tunneling of the RMI communication channels used
in remote testing, since JMeter 2.6:

Заключение

В этой статье мы рассмотрели тестирование производительности базы данных с помощью JMeter путем увеличения пользовательской нагрузки.

Полученные в ходе тестирования показатели могут использоваться в Performance Tuning Engineer для выявления слабых мест производительности.

Пожалуйста, оставляйте ваши комментарии по текущей теме материала. Мы крайне благодарны вам за ваши комментарии, подписки, отклики, лайки, дизлайки!

Пожалуйста, оставляйте свои отзывы по текущей теме статьи. Мы очень благодарим вас за ваши комментарии, отклики, дизлайки, лайки, подписки!

Вадим Дворниковавтор-переводчик статьи «Database Performance Testing with Apache JMeter»