Prestatievergelijking tussen ZeroMQ, RabbitMQ en Apache Qpid

Ik heb een krachtige berichtenbus nodig voor mijn toepassing, dus ik evalueer de prestaties van ZeroMQ , RabbitMQ en Apache Qpid . Om de prestaties te meten, voer ik een testprogramma uit dat bijvoorbeeld 10.000 berichten publiceert met behulp van een van de berichtenwachtrij-implementaties en een ander proces uitvoert op dezelfde machine om deze 10.000 berichten te consumeren. Vervolgens neem ik tijdsverschil op tussen het eerste bericht dat is gepubliceerd en het laatste bericht dat is ontvangen.

Hieronder volgen de instellingen die ik heb gebruikt voor de vergelijking.

  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.

Hieronder volgt het resultaat van de uitvoering:

  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.

Vragen:

  1. Heeft iemand vergelijkbare prestatievergelijkingen tussen de berichtwachtrijen? Vervolgens vergelijk ik mijn resultaten graag met de uwe.
  2. Kan ik RabbitMQ of Qpid op een betere manier afstemmen?

Opmerking:

De tests zijn uitgevoerd op een virtuele machine met twee toegewezen processoren. Het resultaat kan variëren voor verschillende hardware, maar ik ben vooral geïnteresseerd in relatieve prestaties van de MQ-producten.

 68
toegevoegd bewerkt
Bekeken: 6
de bron
elk bericht was hoeveel bytes toen u deze test deed?
toegevoegd de auteur arsenal, de bron
Probeer nanomsg - nog een nakomeling, ontwikkeld door Martin Sustrik, de ZeroMQ mede-vader. Een goede plaats om te beginnen is >>> nanomsg.org/documentation-zeromq.html
toegevoegd de auteur user3666197, de bron
Hier is een goede vergelijking, gedateerd 10 april 2013: x-aeon.com/wp/2013/04/10/…
toegevoegd de auteur Daniel F, de bron
Een vergelijking van de prestaties van RabbitMQ, Kafka, HornetQ, SQS en op Mongo gebaseerde gerepliceerde wachtrijen: warski.org/blog/2014/07/…
toegevoegd de auteur adamw, de bron
Een bijgewerkte versie van KonijnMQ, Kafka, HornetQ, ActiveMQ, SQS en Mongo-prestatievergelijking is nu hier: softwaremill.com/mqperf
toegevoegd de auteur adamw, de bron
Ik heb maanden geleden eenvoudige tests uitgevoerd met vergelijkbare resultaten. En ik merkte op dat het systeem vrij ongebruikt is bij het werken met RabbitMQ of Qpid. Ik denk dat er iets niet klopt.
toegevoegd de auteur Gary Shi, de bron
"RabbitMQ: het duurt ongeveer 12 seconden om 10.000 berichten te ontvangen." - In onze eigen tests zien we regelmatig 20-25.000/sec binnendringen per CPU. U doet dus iets verkeerd of gebruikt een trage client. Heb je al eens geprobeerd konijnmq te e-mailen met vragen?
toegevoegd de auteur user1021067, de bron

8 antwoord

RabbitMQ doet waarschijnlijk persistentie op die berichten. Ik denk dat je de berichtprioriteit moet instellen of een andere optie in berichten om geen persistentie te maken. De prestaties zullen dan 10x verbeteren. Je zou tenminste 100K berichten/seconde moeten verwachten via een AMQP-broker. In OpenAMQ kregen we prestaties tot 300K berichten/seconde.

AMQP was ontworpen voor snelheid (het pakt bijvoorbeeld geen berichten uit om ze te routeren), maar ZeroMQ is eenvoudigweg beter ontworpen op belangrijke manieren. Bijv. het verwijdert een hop door knopen te verbinden zonder een makelaar; het doet een betere asynchrone I/O dan elk van de AMQP client-stacks; het doet agressievere berichtbatching. Misschien ging 60% van de tijd besteed aan het bouwen van ZeroMQ naar het afstemmen van de prestaties. Het was heel zwaar werk. Het is niet per ongeluk sneller.

Een ding dat ik zou willen doen, maar ik heb het te druk, is om een ​​AMQP-achtige makelaar na te bootsen bovenop ZeroMQ. Er is hier een eerste laag: http://rfc.zeromq.org/spec:15 . De hele stapel zou enigszins werken als RestMS, waarbij transport en semantiek in twee lagen zijn verdeeld. Het zou dezelfde functionaliteit bieden als AMQP/0.9.1 (en semantisch interoperabel zijn) maar aanzienlijk sneller.

84
toegevoegd
de bron
RIP mate, je hebt geweldige dingen gebouwd
toegevoegd de auteur RPGillespie, de bron
we zullen Rabbitmq blijven gebruiken totdat iemand met een betere oplossing komt dan @ Piet btw. het doet me denken aan een geweldig patentenverhaal [1]. [1] youtube.com/watch?v=5QqbDyZ8Eu4
toegevoegd de auteur Kunthar, de bron

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 en 0MQ richten zich op verschillende aspecten van berichtenuitwisseling. 0MQ legt veel meer nadruk op hoe de berichten over de draad worden overgedragen. RabbitMQ, aan de andere kant, richt zich op hoe berichten worden opgeslagen, gefilterd en gemonitord.

(Ik hou ook van het bovenstaande KonijnMQ bericht hierboven, omdat het ook gaat over het gebruik van ZeroMQ met 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
toegevoegd
de bron
Ja, ik heb verklaard dat het geen makelaar heeft en gekoppeld is aan een artikel in broker versus makelaar. Was dat niet duidelijk? Ook toen ik dit antwoord in 2011 plaatste, was er geen Malamute, die oktober 2014 verscheen
toegevoegd de auteur Steve Casey, de bron
ZeroMQ heeft geen makelaar. U ontwerpt de broker als een onderdeel van het algehele ontwerp van de toepassing en uw makelaar luistert naar een zeromq, routeringsberichten die geschikt zijn voor hun bestemming. ZeroMQ doet maar één klus en doet het heel goed: message queueing. Er is Malamute, een implementatie van broker ontworpen voor ZeroMQ door de mensen van ZeroMQ, maar het is geen deel uit van de doos van ZeroMQ. Het is een service die u samen met ZeroMQ kunt installeren in zijn eigen proces of in een aparte box (sen) die is gewijd aan berichtendistributie. Het is zijn eigen project. github.com/zeromq/malamute
toegevoegd de auteur user356540, de bron

Ik gebruik een tussenhandelaar in plaats van peer to peer-communicatie in ZeroMQ om de prestatievergelijking eerlijk te laten verlopen naar andere berichtenwachtrij-implementaties die gebruikmaken van tussenpersonen.

Weet niet zeker waarom je dat wilt doen - als het enige waar je om geeft de prestaties zijn, hoef je het speelveld niet te verbeteren. Als je niet om persistentie, filtering, etc. geeft, waarom betaal je dan de prijs?

Ik ben ook heel achterdochtig over het uitvoeren van benchmarks op VM's - er zijn veel extra lagen die de resultaten kunnen beïnvloeden op manieren die niet voor de hand liggen. (Tenzij je van plan bent om het echte systeem op VM's te draaien, in welk geval dat een zeer geldige methode is).

4
toegevoegd
de bron

Ik heb c ++/qpid getest

Ik stuurde 50000 berichten per seconde tussen twee verschillende machines gedurende lange tijd zonder wachtrijen.

Ik heb geen fanout gebruikt, alleen een eenvoudige uitwisseling (niet-persistente berichten)

Gebruikt u persistente berichten? Scant u de berichten?

Ik veronderstel van niet, omdat 0MQ geen berichtstructs heeft.

Als de broker voornamelijk inactief is, hebt u waarschijnlijk de prefetch op afzender en receptor niet geconfigureerd. Dit is erg belangrijk om veel berichten te verzenden.

3
toegevoegd
de bron
Ik gebruik een niet-duurzame wachtrij, ik ontleed het bericht niet. Eigenlijk gebruik ik dezelfde code om berichten te genereren voor alle drie wachtrijexperimenten. Het wijzigen van het ruiltype naar direct had geen effect op de prestaties. Ook na het gebruiken van de flowcontrole van de zender (api sender.SetCapaclity (8)), werd de timing slechter. zonder de flowcontrole van de zender lijkt de wachtrij onbegrensd te worden. Hebt u tijdens het meten van de tijd gewacht tot alle berichten zijn ontvangen en de wachtrij volledig is leeggemaakt?
toegevoegd de auteur ahsankhan, de bron
Ik vond dat qpid-perftest programma Qpid's "oude berichten Apis" gebruikt. Overschakelen naar de oude Apis verbeterde 10 keer in mijn test.
toegevoegd de auteur ahsankhan, de bron

ik denk dat als je bleekselderij gebruikt, de Rabbitmq-prestaties verbeteren

3
toegevoegd
de bron
Het OP vermeldt niet het gebruik van python, en je moet er rekening mee houden dat terwijl een grote bibliotheek, bleekselderij geen zwarte magie is en het niet zal gebruiken om rabbitmq sneller te maken door het gewoon te gebruiken.
toegevoegd de auteur gawry, de bron

We hebben RabbitMQ vergeleken met onze SocketPro ( http://www.udaparts.com/ ) permanente berichtenwachtrij bij de site http://www.udaparts.com/document/articles/fastsocketpro.htm met alle broncodes. Dit zijn de resultaten die we hebben behaald voor RabbitMQ:

Dezelfde machine in wachtrij plaatsen en uit de wachtrij halen:

"Hallo wereld" -
  Enqueue: 30000 berichten per seconde;
  Wachtrij: 7000 berichten per seconde.

     

Tekst met 1024 bytes -
  Enqueue: 11000 berichten per seconde;
  Wachtrij: 7000 berichten per seconde.

     

Tekst met 10 * 1024 bytes -
  Enqueue: 4000 berichten per seconde;
  Wachtrij: 4000 berichten per seconde.

In wachtrij plaatsen en uit de wachtrij halen met een netwerkbandbreedte van 100 mbps:

"Hallo wereld" -
  Enqueue: 28000 berichten per seconde;
  Wachttijd: 1900 berichten per seconde.

     

Tekst met 1024 bytes -
  Enqueue: 8000 berichten per seconde;
  Wachtrij: 1000 berichten per seconde.

     

Tekst met 10 * 1024 bytes -
  Enqueue: 800 berichten per seconde;
  Wachtrij: 700 berichten per seconde.

1
toegevoegd
de bron

We hebben een open source-berichtenbus ontwikkeld die bovenop ZeroMQ is gebouwd - aanvankelijk deden we dit om Qpid te vervangen. Het is brokerloos, dus het is een volkomen eerlijke vergelijking, maar het biedt dezelfde functionaliteit als oplossingen voor bemiddeling.

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
toegevoegd
de bron

Probeer prefetch op afzender en receptor te configureren met een waarde van 100. Prefetching just afzender is niet genoeg

0
toegevoegd
de bron
Fro qpid, ik had de indruk dat Receiver.setCapacity (100) de prefetch voor ontvanger instelt. Na dat te hebben gedaan verbeterden de prestaties 10 keer voor de code met "nieuwe qpid api" en de prestatie was vergelijkbaar met de Qpid oude berichten Api. Ik heb het bericht met het resultaat bijgewerkt. Qpid lijkt echter nog steeds 4 keer langzamer te zijn dan konijnmq.
toegevoegd de auteur ahsankhan, de bron