Автор: Роман Денисенко, старший инженер по тестированию 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 — однако вы можете назначить его вручную.


5. Execution. Последний шаг довольно прост. Нужно запустить JMeter и проверить, что все серверы работают правильно. Для этого можно попробовать запустить распределенную нагрузку с помощью пункта меню: Run -> Remote Start All. Данный пункт позволяет запустить нагрузку с использованием всех указанных ранее серверов. Если требуется использовать только определенный сервер, следует выбрать Run -> Remote Start -> [SERVER], где [SERVER] — адрес сервера, который был добавлен в property-файл на 4-м шаге и запущен на клиентском машине на 3-м шаге.

6.


Заключение.

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

Полезные ссылки

jmeter.apache.org/usermanual/remote-test.htm
jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
gerardnico.com/wiki/jmeter/remote
www.guru99.com/jmeter-distributed-testing.html

Комментарии (4)


  1. ppopoff
    25.12.2015 01:19
    +2

    И в чем ценность этой статьи? Рассказать о том как скачать и установить Jmeter? Можно прочитать официальную документацию. Статья короткая — воды много. Описание реального опыта использования (примеры) отсутствуют.


  1. XNoNAME
    25.12.2015 09:45

    А агенты не тратят ресурсы на отправку статистики на master? Не забивают тем самым канал? Или статистика отправляется уже после тестов?


    1. aboyev
      25.12.2015 14:21

      Агенты только пишут локальные логи запросов. После тестирования их можно собрать в одном месте и проанализировать, построить статистику и пр.


  1. aboyev
    25.12.2015 14:16
    -1

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