Сравнение производительности между ZeroMQ, RabbitMQ и Apache Qpid

Question

Мне нужна высокопроизводительная шина сообщений для моего приложения, поэтому я оцениваю производительность ZeroMQ, RabbitMQ и Apache Qpid. Чтобы измерить производительность, я запускаю тестовую программу, которая публикует, скажем, 10000 сообщений, используя одну из реализаций очереди сообщений, и запускаю другой процесс на том же компьютере, чтобы использовать эти 10000 сообщений. Затем я записываю разницу во времени между первым опубликованным сообщением и последним полученным сообщением.

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

1. RabbitMQ: я использовал обмен типа "fanout" и очередь с конфигурацией по умолчанию. Я использовал клиентскую библиотеку RabbitMQ C.
2. ZeroMQ: мой издатель публикует на tcp://localhost:port1 с сокетом ZMQ_PUSH, мой брокер прослушивает tcp://localhost:port1 и отправляет сообщение на tcp: // localhost: port2, а мой потребитель прослушивает tcp://localhost:port2 с использованием ZMQ_PULL разъем. Я использую посредник вместо одноранговой связи в ZeroMQ, чтобы сделать сравнение производительности справедливым с другой реализацией очереди сообщений, в которой используются посредники.
3. Qpid C ++ брокер сообщений: я использовал обмен типа «разветвление» и очередь с конфигурацией по умолчанию. Я использовал клиентскую библиотеку Qpid C ++.

Ниже приведен результат производительности:

1. RabbitMQ: получение 10000 сообщений занимает около 1 секунды.
2. ZeroMQ: получение 10000 сообщений занимает около 15 миллисекунд.
3. Qpid: получение 10000 сообщений занимает около 4 секунд.

Вопросы:

1. Кто-нибудь запускал аналогичное сравнение производительности между очередями сообщений? Тогда мне нравится сравнивать свои результаты с вашими.
2. Можно ли как-нибудь настроить RabbitMQ или Qpid, чтобы улучшить производительность?

Примечание:

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

Answer 1

RabbitMQ, вероятно, делает постоянство над этими сообщениями.Я думаю, что вам нужно установить приоритет сообщения или другой параметр в сообщениях, чтобы не делать постоянство.Производительность улучшится в 10 раз.Вы должны ожидать, по крайней мере, 100K сообщений в секунду через брокера AMQP.В OpenAMQ мы получили производительность до 300 тыс. Сообщений в секунду.

AMQP был предназначен для скорости (например, он не распаковывает сообщения для их маршрутизации), но ZeroMQ просто лучше разработан в ключепути.Например, он удаляет переход, соединяя узлы без посредника;это делает лучше асинхронный ввод-вывод, чем любой из стеков клиента AMQP;это делает более агрессивное пакетирование сообщений.Возможно, 60% времени, потраченного на создание ZeroMQ, ушло на настройку производительности.Это была очень тяжелая работа.Случайно не быстрее.

Одна вещь, которую я хотел бы сделать, но я слишком занят, это воссоздать AMQP-подобного брокера поверх ZeroMQ.Здесь есть первый слой: http://rfc.zeromq.org/spec:15. Весь стек будет работать как RestMS, с транспортом и семантикой, разделенными на два уровня.Он обеспечит почти такую ​​же функциональность, как AMQP / 0.9.1 (и будет семантически совместимым), но значительно быстрее.

Answer 2

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

Блог RabbitMQ :

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

(мне также нравится вышеупомянутый пост RabbitMQ выше, поскольку он также говорит об использовании ZeroMQ с RabbitMQ)

Итак, я пытаюсь сказать, что вы должны выбрать технологию, которая наилучшим образом соответствует вашим требованиям. Если единственным требованием является скорость, ZeroMQ. Но если вам нужны другие аспекты, такие как сохранение сообщений, фильтрация, мониторинг, отработка отказа и т. Д., Тогда вам нужно начать рассматривать RabbitMQ & Qpid.

Answer 3

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

Не уверен, почему вы хотите это сделать - если единственное, что вас волнует, это производительность, вам не нужно повышать уровень игрового поля. Если вам не нужны постоянство, фильтрация и т. Д., Тогда зачем платить цену?

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

Answer 4

Я тестировал c ++ / qpid

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

Я не использовал разветвление, просто обмен (непостоянные сообщения)

Вы используете постоянные сообщения? Вы анализируете сообщения?

Полагаю, что нет, поскольку в 0MQ нет структур сообщений.

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

Answer 5

Мы сравнили RabbitMQ с нашей SocketPro (http://www.udaparts.com/) постоянная очередь сообщений на сайте http://www.udaparts.com/document/articles/fastsocketpro.htm со всеми исходными кодами. Вот результаты, полученные для RabbitMQ:

Одна и та же машина в очереди и в очереди:

"Привет, мир" -
Постановка в очередь: 30000 сообщений в секунду;
Dequeue: 7000 сообщений в секунду.

Текст с 1024 байтами -
Постановка в очередь: 11000 сообщений в секунду;
Dequeue: 7000 сообщений в секунду.

Текст с 10 * 1024 байтами -
Постановка в очередь: 4000 сообщений в секунду;
Dequeue: 4000 сообщений в секунду.

Перечисление и извлечение между компьютерами с пропускной способностью сети 100 Мбит / с:

"Привет, мир" -
Постановка в очередь: 28000 сообщений в секунду;
Dequeue: 1900 сообщений в секунду.

Текст с 1024 байтами -
Постановка в очередь: 8000 сообщений в секунду;
Dequeue: 1000 сообщений в секунду.

Текст с 10 * 1024 байтами -
Постановка в очередь: 800 сообщений в секунду;
Dequeue: 700 сообщений в секунду.

Answer 6

Мы разработали шину сообщений с открытым исходным кодом, построенную поверх ZeroMQ - мы изначально сделали это, чтобы заменить Qpid.Это без посредников, так что это абсолютно справедливое сравнение, но оно обеспечивает ту же функциональность, что и брокерские решения.

Наш основной показатель производительности составляет 140 Кбит / с на секунду между двумя машинами, но вы можете увидеть более подробную информацию здесь: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

Answer 7

Я думаю, что если вы используете сельдерей, производительность Rabbitmq улучшится

Answer 8

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