Статьи

Сравнительный анализ JMS-слоя с JMSTester

Для большинства клиентов, с которыми я был, масштабирование уровня обмена сообщениями JMS с ActiveMQ является приоритетом. Есть несколько способов достичь этого, но, без сомнения, создание эталонных тестов и анализ архитектуры на реальном оборудовании (или, как говорит мой коллега Гэри Талли «спросить машину») — это первый шаг. Но какие варианты с открытым исходным кодом у вас есть для создания набора всеобъемлющих тестов?

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

Беседуя с Гэри о настройке тестовых сценариев для ActiveMQ, он вспомнил, что в репозитории FuseSource Forge под названием JMSTester появился очень интересный проект. Он предложил мне взглянуть на это. Я сделал, и я был впечатлен его текущими возможностями. Он был создан бывшим консультантом FuseSource , Андресом Гисом , на протяжении многих итераций с клиентами, перелетами и взломом в свободное время. С тех пор я взял это на себя, и я буду добавлять функции, тесты, документы и продолжать импульс, который когда-то был.

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

Цель

Целью этой записи в блоге является ознакомительное введение в инструмент JMSTester. Цель этого инструмента — предоставить мощную платформу для сравнительного анализа для создания гибких распределенных JMS-тестов, в то же время отслеживая / записывая статистику, имеющуюся в наличии, прежде чем вносить изменения и настраивать слой JMS.

Некоторые документы с домашней страницы JMSTester немного устарели, но шаги, описывающие некоторые из тестов, все еще точны. В этом руководстве вам потребуется загрузить SNAPSHOT, над которым я работал, и найти его можно здесь: jmstester-1.1-20120904.213157-5-bin.tar.gz . Я скоро разверну следующую версию веб-сайта, которая должна иметь более обновленные версии двоичных файлов. Когда я это сделаю, я обновлю этот пост.

Познакомьтесь с инструментом JMSTester

Инструмент JMSTester — это просто инструмент, который отправляет и получает сообщения JMS. Вы используете профили, определенные в конфигурационных файлах Spring, чтобы указать, какую нагрузку вы хотите создать в вашем брокере сообщений. JMSTester позволяет вам определять количество производителей, которых вы хотите использовать, количество потребителей, фабрики соединений, свойства JMS (транзакции, сессионные подтверждения и т. Д.) И т. Д. Но действительно крутая часть заключается в том, что вы можете запускать тесты, распределенные по многим машинам. , Это означает, что вы настраиваете машины так, чтобы они действовали как производители, а другие — как потребители. Что касается мониторинга и сбора статистики для сравнительного анализа, JMSTester собирает информацию в трех различных категориях:

  1. Базовый: количество сообщений на одного потребителя, размер сообщения
  2. JMX: отслеживайте любые свойства JMX в посреднике во время выполнения тестов, включая количество потоков, размер очереди, время постановки в очередь и т. Д.
  3. Машина: процессор, системная память, своп, метрики файловой системы, сетевой интерфейс, таблицы маршрутов / соединений и т. Д.

Библиотека Hyperic SIGAR используется для сбора статистики на уровне машины (группа 3), а библиотека RRD4J используется для регистрации статистики и графиков вывода. На данный момент я считаю, что графики довольно просты, и я надеюсь улучшить их, но необработанные данные всегда выгружаются в CSV-файл, и вы можете использовать свое любимое программное обеспечение для создания электронных таблиц для создания собственных графиков.

Архитектура

Инструмент JMSTester состоит из следующих понятий:

  • контроллер
  • клиенты
  • самописец
  • Внешний интерфейс
  • Конфигурация теста

контроллер

Контроллер является организатором бенчмарка. Он отслеживает, кто интересуется командами тестирования, запускает тесты, отслеживает количество потребителей, количество производителей и т. Д. Тест не может работать без контроллера. Для тех, кто заинтересован, базовая архитектура инструмента JMSTester основана на обмене сообщениями, а ActiveMQ является посредником, который запускает контроллер для работы остальной архитектуры.

клиенты

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

самописец

Клиенты индивидуально записывают статистику и отправляют данные на регистратор. Рекордер заканчивает тем, что организует статистику и собирает графики, базы данных RRD4J и эталонные CSV-файлы.

Внешний интерфейс

Интерфейс — это то, что отправляет команды контроллеру. Прямо сейчас есть только интерфейс командной строки, но мои намерения включают в себя веб-интерфейс с REST-контроллером, который можно использовать для запуска тестов.

Конфигурация теста

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

Пошли!

На сайте JMSTester есть несколько хороших вводных уроков:

  • Просто: http://jmstester.fusesource.org/documentation/manual/TutorialSimple.html
  • JMX Probes: http://jmstester.fusesource.org/documentation/manual/TutorialProbes.html
  • Распространено: http://jmstester.fusesource.org/documentation/manual/TutorialDistributed.html

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

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

Архитектура для учебника будет следующей:

Давайте разберемся с диаграммой очень быстро.

На хосте JMS будут запущены два процесса: брокер ActiveMQ, который мы будем тестировать, и клиентский контейнер JMSTester с именем Monitor . Контейнер не будет ни производителем, ни контейнером, но вместо этого будет использоваться только для мониторинга статистики компьютера и JMX. Статистика будет отправлена ​​обратно на рекордер на хосте контроллера, как описано выше в разделе «Рекордер». Контейнеры Producer и Consumer будут запускаться на отдельных машинах с именами соответственно Producer и Consumer . И, наконец, на хосте Controller будут компоненты Controller и Recorder распределенного теста.

Начальная настройка

Загрузите и распакуйте двоичные файлы JMSTester на каждом компьютере, который будет участвовать в тесте производительности .

Запуск контейнеров Контроллер и Регистратор

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

1
./bin/runBenchmark -controller -recorder -springConfigLocations conf/testScripts

Обратите внимание, что все должно быть напечатано точно так, как указано выше, в том числе без пробелов в ‘conf / testScripts’
Это особенность, которую я буду смягчать в рамках своих будущих улучшений.

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

Запуск контейнера производителя

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

1
./bin/runBenchmark -clientNames Producer -hostname domU-12-31-39-16-41-05.compute-1.internal

Для параметра -hostname необходимо указать имя хоста, с которого вы запустили контроллер. Я использую Amazon EC2 выше, и если вы делаете то же самое, предпочитаете использовать внутреннее DNS-имя для хостов.

Запуск потребительского контейнера

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

1
./bin/runBenchmark -clientNames Consumer -hostname domU-12-31-39-16-41-05.compute-1.internal

Опять же, параметр -hostname должен отражать хост, на котором вы запускаете контроллер.

Настройка ActiveMQ и монитора на хосте JMS

Настройка ActiveMQ выходит за рамки этой статьи.
Но вам нужно будет включить JMX на брокере. Просто следуйте инструкциям на веб-сайте Apache ActiveMQ.

Эта следующая часть необходима, чтобы разрешить зонд / мониторинг на уровне машины. Вам нужно будет установить библиотеки SIGAR. Они не распространяются вместе с JMSTester из-за своей лицензии, а их библиотеки JNI недоступны в Maven. По сути, все, что вам нужно сделать, это загрузить и извлечь [дистрибутив SIGAR отсюда] [sigar-distro] и скопировать все $SIGAR_HOME/sigar-bin/lib из $SIGAR_HOME/sigar-bin/lib в вашу папку $ JMSTESTER_HOME / lib.

Теперь запустите контейнер Monitor с помощью аналогичной команды для производителя и потребителя: <

1
./bin/runBenchmark -clientNames Monitor -hostname domU-12-31-39-16-41-05.compute-1.internal

Отправка учебного теста

Мы можем отправить тестовый пример с любого компьютера. Я решил сделать это с моей локальной машины. Вы заметите, что машина, с которой вы отправляете тестовый пример, не отражена на диаграмме сверху; это просто потому, что мы можем сделать это с любой машины. Однако, как и другие команды, вам все равно понадобятся двоичные файлы JMSTester.

Прежде чем запустить тест, давайте кратко рассмотрим конфигурационный файл Spring, в котором указан тест. Для этого откройте файл $ JMSTESTER_HOME / conf / testScripts / tutorial / benchmark.xml в своем любимом текстовом редакторе, желательно в цветном коде XML-документов, чтобы его было легче читать. Файл эталона снабжен множеством комментариев, которые четко описывают отдельные разделы. Если что-то не понятно, пожалуйста, напишите мне, чтобы я мог предоставить более подробную информацию.

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

Посмотрите, где создаются фабрики соединений JMS-брокера. В этом случае именно здесь создаются фабрики соединений ActiveMQ (строки 120 и 124.) Здесь указывается URL-адрес для брокера ActiveMQ, который вы начали в одном из предыдущих разделов. Как он распространяется, там есть URL хоста EC2. Вы должны указать свой собственный хост. Опять же, если вы используете EC2, предпочтите внутренние имена DNS.

Затем взгляните на строку 169, где указан AMQDestinationProbe. Этот зонд является JMX-зондом, специфичным для ActiveMQ. Вы должны изменить свойство brokerName чтобы оно совпадало с тем, что вы назвали своим брокером, когда вы его запустили (обычно это можно найти в разделе <broker brokerName='name here'> вашей конфигурации брокера).

Наконец, из каталога $ JMSTESTER_HOME выполните следующую команду:

1
./bin/runCommand -command submit:conf/testScripts/tutorial -hostname ec2-107-21-69-197.compute-1.amazonaws.com

Опять же, обратите внимание, что я устанавливаю параметр -hostname для хоста, на котором работает контроллер. В этом случае мы предпочитаем общедоступный DNS EC2, но это будет все, что у вас есть в вашей среде.

Выход

Там у вас есть это. Вы отправили тестовый набор в тестовую структуру. Вы должны увидеть некоторую активность на каждом из клиентов (производитель, потребитель, монитор), а также на контроллере. Если ваш тест был выполнен правильно и все необработанные данные и графики были созданы, вы должны увидеть что-то похожее на запись в журнале:

1
Written probe Values to : /home/ec2-user/dev/jmstester-1.1-SNAPSHOT/tutorialBenchmark/benchmark.csv

Обратите внимание, что все результаты записываются в tutorialBenchmark, который является именем теста, как определено параметром benchmarkId в конфигурационном файле Spring в строке 18:

1
<property name='benchmarkId' value='tutorialBenchmark'/>

Если вы посмотрите на файл benchmark.csv , вы увидите всю собранную статистику. Статистические данные для этого урока, которые были собраны, включают следующее:

  • количество сообщений
  • размер сообщения
  • JMX QueueSize
  • JMX ThreadCount
  • SIGAR CpuMonitor
  • SIGAR Свободная системная память
  • Общая системная память SIGAR
  • SIGAR Бесплатный своп
  • SIGAR Total Swap
  • SIGAR Swap Page In
  • SIGAR Swap Page Out
  • SIGAR Disk Reads (в ​​байтах)
  • SIGAR Disk Write (в байтах)
  • SIGAR Disk Reads
  • SGIAR диск пишет
  • SIGAR Network RX BYTES
  • SIGAR Network RX ПАКЕТЫ
  • SIGAR Network TX BYTES
  • SIGAR Network RX пропал
  • SiGAR Network TX пропал
  • SIGAR Network RX ОШИБКИ
  • SIGAR Network TX ОШИБКИ

это оно

Я настоятельно рекомендую взглянуть на этот проект. Я взял это на вооружение и буду улучшать его, если позволяет время, но я очень ценю любые мысли или предложения о том, как его улучшить или какие варианты использования поддержать. Посмотрите на документацию, которая уже есть, и я буду добавлять больше по мере продвижения.
Если у вас есть вопросы или что-то не работает должным образом, как описано выше, пожалуйста, напишите мне комментарий, отправьте электронное письмо или найдите меня в каналах Apache IRC… Обычно я нахожусь в #activemq и #camel.

Приятного кодирования и не забудьте поделиться!

Ссылка: Сравнительный анализ уровня JMS с помощью инструмента JMSTester с открытым исходным кодом от FuseSource от нашего партнера по JCG Кристиана Поста в блоге