Тесты - сравнение 2-х продуктов

1. IBM MQ против Apache ActiveMQ производительность
обновления сравнения
ПО РОМАН ХАРЬКОВСКИЙ 12 МАРТ А 2015
Эта статья описывает результаты тестов производительности стойких сообщений, которые я провёл за
последние 2 месяца, используя IBM MQ V8.0 (ранее WebSphere MQ) и Apache ActiveMQ 5.11. Оба IBM
и Apache выпустили обновления для программного обеспечения в течение 12 месяцев с момента моего
предыдущего теста в 2014 году (вы можете прочитать больше о прошлом испытании
года конфигурации и результатов или увидеть тест производительности видео здесь ), следовательно,
этот новый раунд испытаний является продолжением. В этой статье я привёл полные инструкции и
методики моего тестирования в Open Source стиле, в том числе полный набор скриптов для установки и
нагрузки, так что читатель может запустить свой собственный тест, чтобы проверить свои результаты.
Несмотря на все предложения подключение приложений и сервисов в рамках предприятия,
ориентированное на сообщение (MOM) по-прежнему остается основным выбором для архитекторов и
разработчиков, чтобы надежно доставлять сообщения. Есть несколько продуктов обмена сообщениями
на рынке, в том числе, IBM WebSphere MQ, Tibco EMS, Progress SonicMQ, Apache ActiveMQ, Pivotal
RabbitMQ и т.д. На поверхности все эти продукты появились, чтобы сделать то же самое - доставить
сообщение из точки А в точка В в безопасной и надежной манере,есть также не надежные варианты
доставки, а также модели публикаций подписки. Однако существуют значительные различия между
этими продуктами в надежности, безопасности, производительности, возможностей администратора и
стоимости.
Прежде чем начать реализацию проекта предприятию необходимо понять технические и экономические
ограничения программного обеспечения, которые вы собираетесь использовать. Я описал некоторые из
распространенных ошибок такого процесса выбора в моем блоге: "Как не купить программное
обеспечение предприятия" .
Для получения дополнительной информации по сравнению IBM MQ и Apache ActiveMQ такие функции
как управление, мониторинг, развертывание, безопасность, и т.д., см мою презентацию с InterConnect
2015 .
ТестоваяконфигурацияПроизводительность
Установки для этого теста очень похожи на испытания с 2014 года, за исключением нового
оборудования и более поздних версий программ из IBM и Apache.Из-за новых аппаратных, результаты
моего теста с 2014 напрямую не сопоставимы с результатами 2015 года Пожалуйста, обратите внимание,
что еще в 2014 году мой сервер имел 3 независимых диска SSD, в то время как новый сервер в 2015 году

2. имел 1 диск SSD, Новый сервер имел более быстрый процессор, больше памяти, более высокую
пропускную способность сети и скоростной SSD диск (ввод-вывод этого одного диска примерно похож
на суммарной ввод-вывод 3 SSD дисков из теста в 2014 году).
Многие шаблоны предприятия для систем доставки сообщений основаны на надежной и
гарантированной доставке. Приведенные ниже данные представляют собой постоянные тесты
сообщениями точка-точка. У меня не было времени для тонкой настройки и правильной оценки
характеристик для не стойких сообщений, так что я оставлю это в качестве упражнения для читателя.
Измерение производительности (бенчмаркинг) может быть сложным и трудоемким. С одной стороны,
есть много различных вариантов для возможных конфигураций аппаратного и программного
обеспечения, драйверов, нагрузки тестовых приложений, и т.д. Независимо от выбора, я уверен, будет
много людей, критикующих мой выбор. Схема ниже показывает конфигурацию тестовой среды,
используемой в тесте.
 Хост-сервер, используемый в тесте является IBM x3630 M4 XSERIES модель 7158AC1, 24 ядер
Intel Xeon E5-2440 процессор 2,40 ГГц @ 0, 256 Гб оперативной памяти, один 300 Гб SSD диск с
IO проходят проверку HDPARM на 460 Мб / сек.
 Драйверы нагрузки клиентов и серверов обмена сообщениями выполняются в VM режиме на
CentOS 2.6.32-504.3.3.el6.x86_64 под контролем VMware ESX 5.0.0 914586.
 Каждая VM имеет 8 процессорныхядер и 40 ГБ оперативной памяти для каждого из двух
виртуальных машин серверови 20 ГБ памяти для загрузки генератора VM.

3.  Системы обмена сообщениями использующиеся в тесте IBM WebSphere MQ v8.0.0.1 и Apache
ActiveMQ 5.11.0 работает на Oracle JDK 8 обновлений 31 и Oracle JDK 1.7.076 (нет ощутимой
разници между управлением Amq на JDK 8 против JDK 7 ).
 Нагрузочный сервер использует в тесте IBM Performance Harness для JMS (см Requestorи
Responderв диаграмме выше).
 Виртуальные машины были соединены между собой с помощью частного изолированной
виртуальной сети с использованием VMXNET3 виртуальный адаптер с 13 Гбит пропускной
способности / сек, как показали измерения Iperf инструмента.
 Вы можете посмотреть видео о том, как все это работает в этом блоге (это видео показывает
тест с 2014, но концепция та же, так что я не стал перезаписывать видео).
Сравнениепроизводительностистойкихсообщениями
Результаты которые можно увидеть на рисунке ниже были получены итерационными настройками
Apache ActiveMQ как и IBM MQ. Я пробовал различные настройки на сервере и на клиенте, пытаясь
найти максимальное количество сообщений в секунду для обоих систем. Оказалось, что для моей
конфигурации (собственный ваш текст будет варьироваться), лучшим показателем пересылки
сообщений было получено с 100 одновременных клиентских Requestor темы выполняющих IBM
Performance Benchmark for JMS (Я провёл испытания с 1 до 150 параллельных потоков). Я испытал
различные размеры сообщений - от 20 байт до 10 МБ. Скорость пересылки сообщения в 20 байт было
очень похоже на 256 байт, так что я не включил его в график. Если вам действительно нужно, чтобы
получить высокую производительность для очень небольших сообщениях, вам лучше использовать
протокол MQTT, у меня не было времени, чтобы экспериментировать с ним. С другой стороны,
производительность 10 Мб сообщений была сильно ограничена в сети из-за обмена с диском, так что я
не включил его в результаты.
Каждый экземпляр сервера имеет 5 request-очередей и 5 reply-очередей, в целом 20 очередей в тесте = 2
* серверы (5 request очередей + 5 reply-очередей). Persistent тест проводился с транзакционными JMS
сообщениями как для WMQ так и Amq. Я экспериментировал с различным числом очередей (от 1 до
100), чтобы получить лучшие результаты для обоих серверов, но производительность MQ и Amq были
более или менее одинаковы для различного числа очередей, так для простоты я оставил результаты,
полученные в конфигурации 20 очередей.
Лучшая производительность была найдена при запуске 2 инстансов IBM MQ Queue и 2 инстансов
Apache ActiveMQ. В этом тесте у меня был только один SSD в моем сервере, но вы можете получить
более высокую производительность, если вы добавите больше SSD-накопителей с различными
менеджерами очередей писать/читать из отдельных накопителей. Как правило, вы хотите IBM MQ
использовать один SSD для файла журнала транзакций и другой SSD для файла данных очереди. В моём
случае тестовой файл данных очереди разделяет SSD с журналом транзакций. Если бы я использовал

4. несколько дисков SSD, я бы был в состоянии работать IBM MQ и ActiveMQ даже быстрее, чем то, что
вы видите ниже, потому что все журналы транзакций и очереди данных можно разделить по отдельным
дискам, и я мог иметь более двух экземпляров сервера на виртуальную машину.
Я запускал несколько тестов 24 часа и столкнулся с проблемой использования Amq LevelDB, так что я
был вынужден перейти к KahaDB для тестирования истинной устойчивой работы. В любом случае, это
KahaDB умолчанию и рекомендуется настойчивость двигатель в ActiveMQ 5.11.Удивительно,
производительность LevelDB не было лучше, а в некоторых случаях хуже, чем KahaDB. Форум
поддержки Apache ActiveMQ не ответили на мои вопросы на эту тему. Я также не получил никакой
поддержки от форуме Apache на несколько других вопросов, которые я размещал там по
рекомендованной конфигурации LevelDB, настройке параметров JVM для лучшей производительности в
Amq окружающей среды и т.д.
Я должен упомянуть, что ActiveMQ отлично работает с KahaDB, когда не требуется
отказоустойчивости, но если вам нужна высокая доступность в кластерной среде с не потерянными или
дублированными сообщениями, ActiveMQ с KahaDB не будет работать, как показано в этом
докладе и этом видео . Вам, вероятно, нужно будет использовать JDBC адаптер с ActiveMQ, как описано
в документации . Однако существенным недостатком является то, что этот JDBC будет работать
значительно медленнее, чем KahaDB. Вы выбираете надежность и отказоустойчивость против
скорости. Я не проверял JDBC адаптер ActiveMQ и не могу сказать, насколько сильно это, но, учитывая
значительные дополнительные работы с базой данных, сети, установки, безопасность, настройка,
обслуживание кажется очень крутой ценой за " бесплатный" Сервер ActiveMQ – это высокая цена не
только с точки зрения аппаратного и лицензий на базы данных, но также расходы на оплату труда,
чтобы сохранить все, что настроено.
Каждый тест проводился по крайней мере, три раза в течение одного часа и результат показан ниже:

5. Нагрузка производства, как правило, имеют множество различных размеровсообщений, но это легко
аппроксимировать характеристики с использованием номера выше в качестве ссылки.Можно изменить
отдельные параметры настройки в WMQ и Amq сделать некоторые сообщения размеры запустить
немного быстрее, за счет замедления другие размеры сообщений. После многих сотен различных
перестановок вариантов настройки я остановился на той, что дал высокую общую производительность
как для MQ и Amq - Причина в том, что производство нагрузка, как правило, имеет сочетание
различных размеров сообщений.
Как вы можете видеть, в моих тестах IBM MQ 8.0 42% до 108% быстрее по сравнению с Apache
ActiveMQ 5.11 стойких испытаний. Что это значит? Вы должны были бы использовать до 108% больше
ресурсов,чтобы выполнить ту же нагрузку на ActiveMQ, как на IBM MQ, который в свою очередь
означает для конфигурации ActiveMQ:
 до двух раз больше стоимости оборудования
 до двух раз центра обработки данных пространство
 до двух раз больше охлаждения
 до двух раз больше мощности
 до двух раз более программного обеспечения, установленного (и дополнительные расходы, если
вы покупаете поддержку ActiveMQ)
 до двух раз больше стоимости администрирования для управления всеми выше

6. Даже если все остальные функции IBM MQ и ActiveMQ были равны (и они не - как вы можете увидеть в
моем другую должность ), сам прирост производительности может оплатить стоимость лицензий IBM
MQ и стоит инвестиций. Вы не должны верить мне на слово. Я сделал все скрипты и параметры
настройки доступными для всех, чтобы загрузить и попробовать из моего Microsoft OneDrive . (Я
перестал использовать Dropbox, потому что они ограничивают ежедневный трафик на смехотворно
малым объёме,а Microsoft OneDrive не имеет такого ограничения, не говоря уже о том, что я получил 1
Тб пространства при покупке годового абонемента офиса - никогда не думал, что я буду хвалить
Microsoft :-) )
Какдовериеэтотест?
Я работаю на IBM, но я сделал все возможное, когда настройка IBM MQ и Amq, читали публично
доступные руководства производительности от IBM, Apache и Red Hat. Сказав, что нет никакой
гарантии, что я достиг оптимальной производительности как для MQ или Amq. Я уверен, что кто-то в
Великобритании IBM Херсли Lab или кто-то, кто является экспертом производительности Apache
ActiveMQ может сделать вещи пойти немного быстрее. Насколько быстрее? Еще 10%, 20% - я не
знаю. Но, учитывая, что я провел несколько недель настройка обеих систем, я бы не стал ожидать
среднюю конечного пользователя MQ или Amq, чтобы получить лучшие результаты, чем моя. Если
хотите - не стесняйтесь, чтобы посмотреть на мои скрипты и настройки и внести предложения о том, как
улучшить эту работу, я с удовольствием слушаю и повторите испытания.Все это на 100% в открытый
независимого обзора.
Подробное описание методики тестирования можно найти в этом постеости .

7. Установкаинастройка
В полном духе открытости я опубликовал все настройки конфигурации, параметры настройки, а также
скрипт для генерации нагрузки. В следующем блоге я буду публиковать подробные инструкции по
установке. Сейчас вы можете увидеть инструкции по установке испытания 2014 в моей Google Doc .
Я ленивый (в хорошем смысле), поэтому после того, как работал над этим проектом в течение
некоторого времени, я быстро устал от ручного изменения конфигурации клиента и сервера, запуск и
остановка серверов, синхронизацию вариантов настройки TCP и драйвер нагрузки по всем моим
виртуальным машинам и т.д. Так что я написал автоматизированный скрипт, который делает все это в
одном шаге. Чтобы выполнить полностью автоматический тест все, что вам нужно сделать, это войти в
клиент VM и запустить эту команду: ./run.sh . Эта команда будет копировать все файлы конфигурации
из драйвера нагрузки клиента обоих серверов, стартовать менеджеры очередей, стартовать
Responderответчик темы и начать IOSTAT команду для входа процессора, памяти и дискового
пространства в лог-файлы на всех трех виртуальных машин, стартовать Requestorтемы, итерация в
задании нескольких размеров сообщений и настроек тюнинга и окончательно закрепить результаты
производительности от нескольких выходных файлов в один номер на тест. Уф, это было много
автоматизации :-) .

8. Для тех, кто не заинтересован в чтении установить документ, вы можете просто взглянуть на
конфигурации и загрузки скриптов настройки в этой папке Microsoft OneDrive :
PS. Я обнаружил, что писать автоматизированные скрипты было весело в этом проекте. Я едва
удержался от автоматизации до бесконечности - создание модели нейронной сети для автоматического
поиска оптимальных настроек по всем сотен возможных переменных настройки.