Порівняння продуктивності між ZeroMQ, RabbitMQ та Apache Qpid

Мені потрібна шина повідомлень високої продуктивності для мого програми , так що я оцінка продуктивності ZeroMQ, RabbitMQі Apache Qpid. Для вимірювання продуктивності я запускаю тестову програму, яка публікує 10000 повідомлень, використовуючи одну з реалізацій черги повідомлень, і запускаю інший процес на тій самій машині для споживання цих 10000 повідомлень. Потім я фіксую різницю в часі між першим опублікованим повідомленням та останнім отриманим повідомленням.

Нижче наведено налаштування, які я використав для порівняння.

1. RabbitMQ: Я використовував обмін типу "fanout" та чергу з конфігурацією за замовчуванням. Я використовував клієнтську бібліотеку RabbitMQ C.
2. ZeroMQ: Мій видавець публікує за tcp://localhost:port1допомогою ZMQ_PUSHsocket, Мій брокер слухає tcp://localhost:port1і повторно відправляє повідомлення в tcp: // localhost: port2, а мій споживач прослуховує tcp://localhost:port2використання ZMQ_PULLсокета. Я використовую брокера замість однорангового зв'язку для однорангового спілкування, ZeroMQщоб зробити порівняння продуктивності справедливим щодо реалізації іншої черги повідомлень, яка використовує брокери.
3. QpidБрокер повідомлень на C ++: я використовував обмін типом "fanout" та чергу з конфігурацією за замовчуванням. Я використовував клієнтську бібліотеку Qpid C ++.

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

1. RabbitMQ: для отримання 10 000 повідомлень потрібно близько 1 секунди.
2. ZeroMQ: Отримання 10000 повідомлень займає близько 15 мілі секунд.
3. Qpid: Отримання 10000 повідомлень займає близько 4 секунд.

Запитання:

1. Хтось проводив подібне порівняння продуктивності між чергами повідомлень? Тоді я люблю порівнювати свої результати з вашими.
2. Чи можу я якось налаштуватись RabbitMQчи Qpidпокращити продуктивність?

Примітка:

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

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

AMQP був розроблений для швидкості (наприклад, він не розпаковує повідомлення для їх маршрутизації), але ZeroMQ просто краще розроблений ключовими способами. Наприклад, він видаляє стрибок, з'єднуючи вузли без посередника; він робить кращий асинхронний ввід / вивід, ніж будь-який з клієнтських стеків AMQP; він робить більш агресивне групування повідомлень. Можливо, 60% часу, витраченого на створення ZeroMQ, пішло на налаштування продуктивності. Це була дуже важка робота. Це не швидше випадково.

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

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

Блог RabbitMQ :

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

(Мені також подобається вищезазначена публікація RabbitMQ вище, оскільки там також йдеться про використання ZeroMQ із RabbitMQ)

Отже, я намагаюся сказати, що вам слід визначитися з технологією, яка найкраще відповідає вашим вимогам. Якщо єдиною вимогою є швидкість, ZeroMQ. Але якщо вам потрібні інші аспекти, такі як постійність повідомлень, фільтрація, моніторинг, відмовостійкість тощо, тоді вам потрібно почати розглядати RabbitMQ & Qpid.

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

Не впевнений, чому ви хочете це зробити - якщо єдине, що вас турбує, це продуктивність, немає необхідності робити ігрове поле рівним. Якщо ви не дбаєте про наполегливість, фільтрацію тощо, то навіщо платити ціну?

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

Я протестував c ++ / qpid

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

Я не користувався фанатом, просто простим обміном (непостійні повідомлення)

Ви використовуєте постійні повідомлення? Ви розбираєте повідомлення?

Я припускаю, що ні, оскільки 0MQ не має структури повідомлень.

Якщо брокер в основному не працює, ви, мабуть, не налаштували попередню вибірку для відправника та рецептора. Це дуже важливо для надсилання багатьох повідомлень.

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

Однакові черги та зміни в машині:

"Привіт світ" -
Черга: 30000 повідомлень за секунду;
Зняти з черги: 7000 повідомлень у секунду.

Текст з 1024 байтами -
чергу: 11000 повідомлень за секунду;
Зняти з черги: 7000 повідомлень у секунду.

Текст із 10 * 1024 байтами -
Черга: 4000 повідомлень у секунду;
Зняти з черги: 4000 повідомлень у секунду.

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

"Привіт світ" -
Черга: 28000 повідомлень за секунду;
Зняти з черги: 1900 повідомлень у секунду.

Текст із 1024 байтами -
чергу: 8000 повідомлень за секунду;
Зняти з черги: 1000 повідомлень у секунду.

Текст із 10 * 1024 байтами -
чергу: 800 повідомлень у секунду;
Зняти з черги: 700 повідомлень у секунду.

Спробуйте налаштувати попередню вибірку для відправника та рецептора зі значенням, подібним до 100. Попереднього отримання лише відправника недостатньо

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

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