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 году

имел 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.

Системы обмена сообщениями использующиеся в тесте 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 с журналом транзакций. Если бы я использовал

несколько дисков 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 – это высокая цена не

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

чтобы сохранить все, что настроено.

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

 

Нагрузка производства, как правило, имеют множество различных размеров сообщений, но это легко

аппроксимировать характеристики с использованием номера выше в качестве ссылки.Можно изменить

отдельные параметры настройки в WMQ и Amq сделать некоторые сообщения размеры запустить

немного быстрее, за счет замедления другие размеры сообщений. После многих сотен различных

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

как для MQ и Amq - Причина в том, что производство нагрузка, как правило, имеет сочетание

различных размеров сообщений.

Как вы можете видеть, в моих тестах IBM MQ 8.0 42% до 108% быстрее по сравнению с Apache

ActiveMQ 5.11 стойких испытаний. Что это значит? Вы должны были бы использовать до 108% больше

ресурсов, чтобы выполнить ту же нагрузку на ActiveMQ, как на IBM MQ, который в свою очередь

означает для конфигурации ActiveMQ:

до двух раз больше стоимости оборудования

до двух раз центра обработки данных пространство

до двух раз больше охлаждения

до двух раз больше мощности

до двух раз более программного обеспечения, установленного (и дополнительные расходы, если

вы покупаете поддержку ActiveMQ)

до двух раз больше стоимости администрирования для управления всеми выше

Даже если все остальные функции 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% в открытый

независимого обзора.

Подробное описание методики тестирования можно найти в этом постеости .

Установка и настройка

В полном духе открытости я опубликовал все настройки конфигурации, параметры настройки, а также

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

установке. Сейчас вы можете увидеть инструкции по установке испытания 2014 в моей Google Doc .

Я ленивый (в хорошем смысле), поэтому после того, как работал над этим проектом в течение

некоторого времени, я быстро устал от ручного изменения конфигурации клиента и сервера, запуск и

остановка серверов, синхронизацию вариантов настройки TCP и драйвер нагрузки по всем моим

виртуальным машинам и т.д. Так что я написал автоматизированный скрипт, который делает все это в

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

клиент VM и запустить эту команду: ./run.sh . Эта команда будет копировать все файлы конфигурации

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

Responderответчик темы и начать IOSTAT команду для входа процессора, памяти и дискового

пространства в лог-файлы на всех трех виртуальных машин, стартовать Requestor темы, итерация в

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

производительности от нескольких выходных файлов в один номер на тест. Уф, это было много

автоматизации :-) .

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

конфигурации и загрузки скриптов настройки в этой папке Microsoft OneDrive :

PS. Я обнаружил, что писать автоматизированные скрипты было весело в этом проекте. Я едва

удержался от автоматизации до бесконечности - создание модели нейронной сети для автоматического

поиска оптимальных настроек по всем сотен возможных переменных настройки.