Comparación de rendimiento entre ZeroMQ, RabbitMQ y Apache Qpid

78

Necesito un bus de mensajes de alto rendimiento para mi aplicación, así que estoy evaluando el rendimiento de ZeroMQ, RabbitMQy Apache Qpid. Para medir el rendimiento, estoy ejecutando un programa de prueba que publica, digamos, 10,000 mensajes usando una de las implementaciones de la cola de mensajes y ejecutando otro proceso en la misma máquina para consumir estos 10,000 mensajes. Luego registro la diferencia de tiempo entre el primer mensaje publicado y el último mensaje recibido.

A continuación se muestran las configuraciones que utilicé para la comparación.

  1. RabbitMQ: Usé un intercambio de tipo "fanout" y una cola con la configuración predeterminada. Usé la biblioteca cliente de RabbitMQ C.
  2. ZeroMQ: Mi editor publica en tcp://localhost:port1con ZMQ_PUSHsocket, Mi corredor escucha tcp://localhost:port1y reenvía el mensaje a tcp: // localhost: port2 y mi consumidor escucha el tcp://localhost:port2uso de ZMQ_PULLsocket. Estoy usando un intermediario en lugar de la comunicación entre pares ZeroMQpara que la comparación de rendimiento sea justa con otra implementación de cola de mensajes que utiliza intermediarios.
  3. QpidAgente de mensajes C ++: utilicé un intercambio de tipo "fanout" y una cola con la configuración predeterminada. Usé la biblioteca cliente Qpid C ++.

A continuación se muestra el resultado de rendimiento:

  1. RabbitMQ: tarda aproximadamente 1 segundo en recibir 10.000 mensajes.
  2. ZeroMQ: Tarda unos 15 milisegundos en recibir 10.000 mensajes.
  3. Qpid: Tarda unos 4 segundos en recibir 10.000 mensajes.

Preguntas:

  1. ¿Alguien ha realizado una comparación de rendimiento similar entre las colas de mensajes? Entonces me gusta comparar mis resultados con los tuyos.
  2. ¿Hay alguna forma en que pueda ajustar RabbitMQo Qpidmejorar su rendimiento?

Nota:

Las pruebas se realizaron en una máquina virtual con dos procesadores asignados. El resultado puede variar según el hardware; sin embargo, lo que más me interesa es el rendimiento relativo de los productos MQ.

message-queue  rabbitmq  zeromq  qpid 
— ahsankhan
fuente
3
Hace meses que realicé pruebas sencillas con resultados similares. Y noté que el sistema está bastante inactivo cuando se trabaja con RabbitMQ o Qpid. Creo que algo debe andar mal.
— Gary Shi
"RabbitMQ: tarda unos 12 segundos en recibir 10.000 mensajes". - En nuestras propias pruebas, vemos regularmente un ingreso de 20-25,000 / seg por CPU. Entonces, estás haciendo algo mal o estás usando un cliente lento. ¿Ha intentado enviar un correo electrónico a rabbitmq-discus con preguntas?
1
Aquí hay una buena comparación, con fecha del 10 de abril de 2013: x-aeon.com/wp/2013/04/10/…
— Daniel F
3
Una versión actualizada de la comparación de rendimiento de RabbitMQ, Kafka, HornetQ, ActiveMQ, SQS y Mongo ahora está aquí: softwaremill.com/mqperf
— adamw
2
cada mensaje era la cantidad de bytes cuando hizo esta prueba?
— arsenal

Respuestas:

104

RabbitMQ probablemente esté persistiendo en esos mensajes. Creo que necesitas establecer la prioridad del mensaje u otra opción en los mensajes para no tener persistencia. Entonces, el rendimiento mejorará 10 veces. Debería esperar al menos 100.000 mensajes / segundo a través de un agente de AMQP. En OpenAMQ obtuvimos un rendimiento de hasta 300K mensajes / segundo.

AMQP fue diseñado para la velocidad (por ejemplo, no descomprime los mensajes para enrutarlos) pero ZeroMQ simplemente está mejor diseñado en formas clave. Por ejemplo, elimina un salto conectando nodos sin un intermediario; realiza mejor E / S asincrónica que cualquiera de las pilas de clientes AMQP; realiza un procesamiento por lotes de mensajes más agresivo. Quizás el 60% del tiempo dedicado a la construcción de ZeroMQ se dedicó al ajuste del rendimiento. Fue un trabajo muy duro. No es más rápido por accidente.

Una cosa que me gustaría hacer, pero estoy demasiado ocupado, es recrear un corredor similar a AMQP sobre ZeroMQ. Aquí hay una primera capa: http://rfc.zeromq.org/spec:15 . Toda la pila funcionaría como RestMS, con transporte y semántica separados en dos capas. Proporcionaría prácticamente la misma funcionalidad que AMQP / 0.9.1 (y sería semánticamente interoperable) pero significativamente más rápido.

— Pieter Hintjens
fuente
Continuaremos usando rabbitmq hasta que alguien encuentre una solución mejor que @pieter por cierto. me recuerda una gran historia de patentes [1]. [1] youtube.com/watch?v=5QqbDyZ8Eu4
— Kunthar
57
RIP amigo, construiste algunas cosas geniales
— Gillespie
33

Hmm, por supuesto que ZeroMQ será más rápido, está diseñado para serlo y no tiene muchas de las funciones basadas en broker que ofrecen los otros dos. El sitio de ZeroMQ tiene una comparación maravillosa entre la mensajería de intermediario y la mensajería sin intermediario y los inconvenientes y ventajas de ambos.

Blog de RabbitMQ :

RabbitMQ y 0MQ se centran en diferentes aspectos de la mensajería. 0MQ pone mucho más énfasis en cómo se transfieren los mensajes por cable. RabbitMQ, por otro lado, se centra en cómo se almacenan, filtran y monitorean los mensajes.

(También me gusta la publicación anterior de RabbitMQ, ya que también habla sobre el uso de ZeroMQ con RabbitMQ)

Entonces, lo que estoy tratando de decir es que debe decidir la tecnología que mejor se adapte a sus requisitos. Si el único requisito es la velocidad, ZeroMQ. Pero si necesita otros aspectos como la persistencia de mensajes, filtrado, monitoreo, failover, etc., entonces es cuando debe comenzar a considerar RabbitMQ & Qpid.

— Steve Casey
fuente
4
ZeroMQ no tiene intermediario. Usted diseña el intermediario como parte del diseño general de la aplicación y su intermediario escucha en un zeromq, enrutando los mensajes según corresponda para su destino. ZeroMQ solo hace un trabajo y lo hace muy bien: poner mensajes en cola. Está Malamute, que es una implementación de corredor diseñada para ZeroMQ por la gente de ZeroMQ, pero no es parte de ZeroMQ lista para usar. Es un servicio que puede instalar junto con ZeroMQ en su propio proceso o en cajas separadas dedicadas a la intermediación de mensajes. Es su propio proyecto. github.com/zeromq/malamute
— Neil Davis
Sí, indiqué que no tiene corredor y está vinculado a un artículo en broker vs brokerless. ¿No quedó claro? Además, cuando publiqué esta respuesta en 2011 no había Malamute, que apareció en octubre de 2014
— Steve Casey
4

Estoy usando un intermediario en lugar de la comunicación entre pares en ZeroMQ para que la comparación de rendimiento sea justa con otra implementación de cola de mensajes que utiliza intermediarios.

No estoy seguro de por qué quiere hacer eso: si lo único que le importa es el rendimiento, no hay necesidad de nivelar el campo de juego. Si no le importa la persistencia, el filtrado, etc., ¿por qué pagar el precio?

También desconfío mucho de ejecutar evaluaciones comparativas en máquinas virtuales: hay muchas capas adicionales que pueden afectar los resultados de formas que no son obvias. (A menos que esté planeando ejecutar el sistema real en VM, por supuesto, en cuyo caso ese es un método muy válido).

— WallStProg
fuente
3

He probado c ++ / qpid

Envié 50000 mensajes por segundo entre dos máquinas diferentes durante mucho tiempo sin hacer cola.

No utilicé un fanout, solo un simple intercambio (mensajes no persistentes)

¿Estás usando mensajes persistentes? ¿Estás analizando los mensajes?

Supongo que no, ya que 0MQ no tiene estructuras de mensajes.

Si el corredor está inactivo principalmente, probablemente no haya configurado la captación previa en el remitente y el receptor. Esto es muy importante para enviar muchos mensajes.

— José Luis
fuente
Estoy usando una cola no duradera, no analizo el mensaje. En realidad, estoy usando el mismo código para generar mensajes para los tres experimentos de cola. Cambiar el tipo de intercambio a directo no tuvo ningún efecto en el rendimiento. Además, después de usar el control de flujo del remitente (api sender.SetCapaclity (8)), el tiempo empeoró. sin el control de flujo del remitente, la cola parece crecer sin límites. Al medir el tiempo, ¿ha esperado hasta recibir todos los mensajes y la cola se agota por completo?
— ahsankhan
1
Encontré que el programa qpid-perftest está usando "Apis de mensajería antigua" de Qpid. Cambiar a la antigua Apis mejoró el rendimiento 10 veces en mi prueba.
— ahsankhan
1

Hemos comparado RabbitMQ con nuestra cola de mensajes persistentes SocketPro ( http://www.udaparts.com/ ) en el sitio http://www.udaparts.com/document/articles/fastsocketpro.htm con todos los códigos fuente. Estos son los resultados que obtuvimos para RabbitMQ:

La misma máquina pone y saca de cola:

"Hola mundo" -
Enqueue: 30000 mensajes por segundo;
Retirar de cola: 7000 mensajes por segundo.

Texto con 1024 bytes -
Enqueue: 11000 mensajes por segundo;
Retirar de la cola: 7000 mensajes por segundo.

Texto con 10 * 1024 bytes -
Enqueue: 4000 mensajes por segundo;
Dequeue: 4000 mensajes por segundo.

Poner en cola y sacar de cola entre máquinas con un ancho de banda de red de 100 Mbps:

"Hola mundo" -
Enqueue: 28000 mensajes por segundo;
Dequeue: 1900 mensajes por segundo.

Texto con 1024 bytes -
Enqueue: 8000 mensajes por segundo;
Retirar de cola: 1000 mensajes por segundo.

Texto con 10 * 1024 bytes -
Enqueue: 800 mensajes por segundo;
Dequeue: 700 mensajes por segundo.

— Comunidad
fuente
0

Intente configurar la captación previa en el remitente y el receptor con un valor como 100. La captación previa solo del remitente no es suficiente

— jale
fuente
Para qpid, tuve la impresión de que Receiver.setCapacity (100) establece la captación previa para el receptor. Después de hacer eso, el rendimiento mejoró 10 veces para el código usando "new qpid api" y el rendimiento se volvió similar a la antigua API de mensajería de Qpid. He actualizado la publicación con el resultado. Sin embargo, Qpid todavía parece ser 4 veces más lento que rabbitmq.
— ahsankhan
0

Hemos desarrollado un bus de mensajes de código abierto construido sobre ZeroMQ; inicialmente lo hicimos para reemplazar Qpid. No tiene intermediarios, por lo que no es una comparación totalmente justa, pero proporciona la misma funcionalidad que las soluciones con intermediarios.

Nuestra cifra de rendimiento principal es de 140.000 mensajes por segundo entre dos máquinas, pero puede ver más detalles aquí: https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

— Slugart
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.