Параўнанне прадукцыйнасці паміж ZeroMQ, RabbitMQ і Apache Qpid

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

Ніжэй прыведзены параметры, якія я выкарыстаў для параўнання.

  1. RabbitMQ: I used a "fanout" type exchange and a queue with default configuration. I used the RabbitMQ C client library.
  2. ZeroMQ: My publisher publises to tcp://localhost:port1 with ZMQ_PUSH socket, My broker listens on tcp://localhost:port1 and resends the message to tcp://localhost:port2 and my consumer listens on tcp://localhost:port2 using ZMQ_PULL socket. I am using a broker instead of peer to to peer communication in ZeroMQ to to make the performance comparison fair to other message queue implementation that uses brokers.
  3. Qpid C++ message broker: I used a "fanout" type exchange and a queue with default configuration. I used the Qpid C++ client library.

Ніжэй прыводзіцца вынік прадукцыйнасці:

  1. RabbitMQ: it takes about 1 second to receive 10,000 messages.
  2. ZeroMQ: It takes about 15 milli seconds to receive 10,000 messages.
  3. Qpid: It takes about 4 seconds to receive 10,000 messages.

Пытанні:

  1. Ёсць хто-небудзь запусціць падобнае параўнанне прадукцыйнасці паміж чэргамі паведамленняў? Тады я хацеў бы параўнаць свае вынікі з вашымі.
  2. Ці ёсць спосаб, якім я мог бы наладзіць RabbitMQ або Qpid , каб зрабіць яго прадукцыйнасць лепш?

<�Моцны> Заўвага:

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

68
кожнае паведамленне было колькі байт, калі вы зрабілі гэты тэст?
дададзена аўтар arsenal, крыніца
Дайце паспрабаваць на nanomsg - іншае нашчадства, які вылучаецца Марцінам Sustrik, у ZeroMQ са-бацька. Добрае месца, каб пачаць чытаць, >>> nanomsg.org/documentation-zeromq.html
дададзена аўтар user3666197, крыніца
Вось добрае параўнанне, ад 10 красавiка 2013: x-aeon.com/wp/2013/04/10/…
дададзена аўтар Daniel F, крыніца
Параўнанне прадукцыйнасці RabbitMQ, Кафка, HornetQ, SQS і Монго на аснове тыражуюцца чэргаў: warski.org/blog/2014/07/…
дададзена аўтар adamw, крыніца
Абноўленая версія RabbitMQ, Кафка, HornetQ, ActiveMQ, SQS і параўнання прадукцыйнасці Монго зараз тут: softwaremill.com/mqperf </а>
дададзена аўтар adamw, крыніца
Я бег простыя тэсты месяцаў таму, з аналагічнымі вынікамі. І я заўважыў, што сістэма даволі бяздзейны пры працы з RabbitMQ або Qpid. Я думаю, што нешта павінна быць няправільным.
дададзена аўтар Gary Shi, крыніца
«RabbitMQ: яна займае каля 12 секунд, каб атрымаць 10000 паведамленняў.» - У нашых тэстах мы рэгулярна бачым 20-25,000/сек трапленню на ЦПУ. Такім чынам, вы робіце нешта няправільна, або з дапамогай павольнага кліента. Ці спрабавалі вы па электроннай пошце RabbitMQ-абмеркаваць пытанні?
дададзена аўтар user1021067, крыніца

8 адказы

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

AMQP WAS прызначана для хуткасці (напрыклад, ён не распакоўвае паведамленні для таго, каб накіроўваць іх), але ZeroMQ проста лепш распрацавана ў ключавых кірунках. напрыклад ён выдаляе хмель, злучыўшы вузлы без брокера; ён робіць лепш асінхронны ўвод/выснова, чым любыя з кліенцкіх стэкаў AMQP; гэта робіць больш агрэсіўныя паведамленне пакетірованія. Магчыма, 60% ад часу, выдаткаванага будаўніцтва ZeroMQ пайшоў у налады прадукцыйнасці. Гэта была вельмі цяжкая праца. Гэта не хутчэй выпадкова.

Адна рэч, якую я хацеў бы зрабіць, але я занадта заняты, каб узнавіць AMQP тыпу брокера на вяршыні ZeroMQ. Існуе першы пласт тут: http://rfc.zeromq.org/spec:15 . Усе стэк будзе працаваць некалькі як RestMS, з транспартам і семантыкай, падзеленай на два пласт. Гэта забяспечыла б вялікую такую ​​ж функцыянальнасць, як AMQP/0.9.1 (і семантычна сумяшчальныя), але значна хутчэй.

84
дададзена
RIP дружа, вы пабудавалі некаторыя вялікія рэчы
дададзена аўтар RPGillespie, крыніца
мы будзем працягваць выкарыстоўваць RabbitMQ пакуль хто-небудзь прыдумаць лепшае рашэнне тады @pieter дарэчы. гэта нагадвае мне вялікую гісторыю патэнтаў [1]. [1] youtube.com/watch?v=5QqbDyZ8Eu4
дададзена аўтар Kunthar, крыніца

Hmm, of course ZeroMQ will be faster, it is designed to be and does not have a lot of the broker based functionality that the other two provide. The ZeroMQ site has a wonderful comparison of broker vs brokerless messaging and drawbacks & advantages of both.

RabbitMQ Blog:

<�Р> RabbitMQ і 0MQ сканцэнтраваны на розных аспектах абмену паведамленнямі. 0MQ ставіць значна больш увагі на тое, як паведамленні перадаюцца па правадах. RabbitMQ, з другога боку, факусуюць на тым, як захоўваюцца паведамлення, фільтруецца і кантралюецца.

(Я таксама, як вышэй RabbitMQ пост вышэй, ён таксама кажа пра выкарыстанне ZeroMQ з RabbitMQ)

So, what I'm trying to say is that you should decide on the tech that best fits your requirements. If the only requirement is speed, ZeroMQ. But if you need other aspects such as persistence of messages, filtering, monitoring, failover, etc well, then that's when u need to start considering RabbitMQ & Qpid.

31
дададзена
Так, я сказаў, што гэта не мае ніякага брокера і звязана артыкул у Брокер супраць brokerless. Гэта было не ясна? Акрамя таго, калі я адправіў гэты адказ у 2011 годзе не было малаает, які з'явіўся кастрычнік 2014
дададзена аўтар Steve Casey, крыніца
ZeroMQ няма брокера. Вы праектуеце брокер ў якасці часткі агульнага дызайну прыкладання і ваш брокер праслухоўвае ZeroMQ, паведамленні аб маршрутызацыі ў залежнасці ад абставін іх прызначэння. ZeroMQ робіць толькі адна праца, і робіць гэта вельмі добра: чэргі паведамленняў. Існуе маламут, што рэалізацыя брокер прызначаны для ZeroMQ людзьмі ZeroMQ, але гэта не частка ZeroMQ з скрынкі. Гэта сэрвіс можна ўсталяваць разам з ZeroMQ ў яго ўласным працэсе або ў асобным акне (ов), прысвечанае паведамлення пасярэдніцтва. Гэта яго ўласны праект. github.com/zeromq/malamute
дададзена аўтар user356540, крыніца
<�Р> Я выкарыстоўваю брокер замест роўнага роўнай сувязі ў ZeroMQ, каб зрабіць параўнанне прадукцыйнасці справядлівым для іншай рэалізацыі чэргі паведамленняў, якая выкарыстоўвае брокер.

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

Я таксама вельмі хітры выкананні тэстаў на ВМ - ёсць шмат дадатковых слаёў, якія могуць паўплываць на вынікі спосабамі, якія не зьяўляюцца відавочнымі. (Калі вы не плануеце запусціць рэальную сістэму на ВМ, вядома, у гэтым выпадку, што з'яўляецца вельмі пэўным метадам).

4
дададзена

Я праверыў з ++/qpid

Я паслаў 50000 паведамленняў у секунду паміж двума машынамі Diferent на працягу доўгага часу без чэргаў.

Я не выкарыстоўваў разгалінаванне, толькі просты абмен (не сталыя паведамленні)

Вы карыстаецеся сталыя паведамленні? Вы разбор паведамленні?

Я мяркую, што няма, паколькі 0MQ не мае паведамленняў структур.

Калі брокер ў асноўным прастойвае, вы, верагодна, не настроены на предвыборку адпраўніка і рэцэптарамі. Гэта вельмі важна, каб адправіць вялікая колькасць паведамленняў.

3
дададзена
Я выкарыстоўваю Ноны даўгавечных чарзе, я не разабраць паведамлення, На самай справе я выкарыстоўваю адзін і той жа код для стварэння паведамленні для ўсіх трох эксперыментаў чарзе. Змена абменнага тыпу прамога не мае ўплыву на прадукцыйнасць. Акрамя таго, пасля выкарыстання кіравання патокам адпраўшчыка (API sender.SetCapaclity (8)), то выбар часу стала яшчэ горш. без кіравання патокам дадзеных адпраўніка, чарга, здаецца, расце неабмежаванае. Пры вымярэнні часу, пакуль вы чакалі да атрымання ўсіх паведамленняў і чарга цалкам зліваюць?
дададзена аўтар ahsankhan, крыніца
Я выявіў, што qpid-perftest праграма выкарыстоўвае Qpid «старыя паведамленні Apis». Пераход да старога Apis павышэння прадукцыйнасці ў 10 разоў у маім цесцю.
дададзена аўтар ahsankhan, крыніца

я думаю, што калі вы выкарыстоўваеце салера, прадукцыйнасць RabbitMQ палепшыцца

3
дададзена
OP не кажучы ўжо аб выкарыстанні пітона, і вы павінны ведаць, што ў той час як вялікую бібліятэку, салера не чорная магія, і не збіраецца рабіць RabbitMQ хутчэй, проста выкарыстоўваючы яго.
дададзена аўтар gawry, крыніца

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

Тое ж Епдиеяя машына і Dequeue:

<�Р> «Прывітанне свет» - Старонка   Ставіць: 30000 паведамленняў у секунду;
  Dequeue: 7000 паведамленняў у секунду. </Р>      <�Р> Тэкст з 1024 байтам - Старонка   Ставіць: 11000 паведамленняў у секунду;
  Dequeue: 7000 паведамленняў у секунду. </Р>      <�Р> Тэкст з 10 * 1024 байтам - Старонка   Ставіць: 4000 паведамленняў у секунду;
  Ведиеие: 4000 паведамленняў у секунду. </Р>

Крос-машына Епдиеие і Dequeue з прапускной здольнасцю сеткі 100 Мбіт:

<�Р> «Прывітанне свет» - Старонка   Ставіць: 28000 паведамленняў у секунду;
  Dequeue: 1900 паведамленняў у секунду. </Р>      <�Р> Тэкст з 1024 байтам - Старонка   Ставіць: 8000 паведамленняў у секунду;
  Dequeue 1000 паведамленняў у секунду. </Р>      <�Р> Тэкст з 10 * 1024 байтам - Старонка   Ставіць: 800 паведамленняў у секунду;
  Dequeue: 700 паведамленняў у секунду. </Р>
1
дададзена

Мы распрацавалі паведамленне аўтобус з адкрытым зыходным кодам, пабудаваны на вяршыні ZeroMQ - мы першапачаткова гэта замяніць Qpid. Гэта brokerless так што гэта цалкам справядлівае параўнанне, але яна забяспечвае такую ​​ж функцыянальнасць як пры пасярэдніцтве рашэнняў.

Our headline performance figure is 140K msgs per second between two machines but you can see more detail here: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

0
дададзена

Паспрабуйце наладзіць предвыборку на адпраўнік і рэцэптар са значэннем як 100. Предзагрузка толькі адпраўнік не дастаткова

0
дададзена
Фро qpid, у мяне стварылася ўражанне, што Receiver.setCapacity (100) устанаўлівае предвыборку для прымача. Afer робіць, што прадукцыйнасць палепшылася ў 10 раз для кода з дапамогай «новага qpid API» і прадукцыйнасць bacame падобная на Qpid старых паведамленняў АПА. Я абнавіў пост з вынікам. Аднак Qpid ўсё яшчэ, здаецца, у 4 разы больш павольна, чым RabbitMQ.
дададзена аўтар ahsankhan, крыніца