Performance comparison between ZeroMQ, RabbitMQ and Apache Qpid

后端 未结 7 1402
伪装坚强ぢ
伪装坚强ぢ 2020-12-12 09:36

I need a high performance message bus for my application so I am evaluating performance of ZeroMQ, RabbitMQ and Apache Qpid. To measur

相关标签:
7条回答
  • 2020-12-12 10:03

    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.

    Not sure why you want to do that -- if the only thing you care about is performance, there is no need to make the playing field level. If you don't care about persistence, filtering, etc. then why pay the price?

    I'm also very leery of running benchmarks on VM's -- there are a lot of extra layers that can affect the results in ways that are not obvious. (Unless you're planning to run the real system on VM's, of course, in which case that is a very valid method).

    0 讨论(0)
  • 2020-12-12 10:03

    We've developed an open source message bus built on top of ZeroMQ - we initially did this to replace Qpid. It's brokerless so it's not a totally fair comparison but it provides the same functionality as brokered solutions.

    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 讨论(0)
  • 2020-12-12 10:06

    We have compared RabbitMQ with our SocketPro (http://www.udaparts.com/) persistent message queue at the site http://www.udaparts.com/document/articles/fastsocketpro.htm with all source codes. Here are results we obtained for RabbitMQ:

    Same machine enqueue and dequeue:

    "Hello world" --
    Enqueue: 30000 messages per second;
    Dequeue: 7000 messages per second.

    Text with 1024 bytes --
    Enqueue: 11000 messages per second;
    Dequeue: 7000 messages per second.

    Text with 10 * 1024 bytes --
    Enqueue: 4000 messages per second;
    Dequeue: 4000 messages per second.

    Cross-machine enqueue and dequeue with network bandwidth 100 mbps:

    "Hello world" --
    Enqueue: 28000 messages per second;
    Dequeue: 1900 messages per second.

    Text with 1024 bytes --
    Enqueue: 8000 messages per second;
    Dequeue: 1000 messages per second.

    Text with 10 * 1024 bytes --
    Enqueue: 800 messages per second;
    Dequeue: 700 messages per second.

    0 讨论(0)
  • 2020-12-12 10:07

    RabbitMQ is probably doing persistence on those messages. I think you need to set the message priority or another option in messages to not do persistence. Performance will improve 10x then. You should expect at least 100K messages/second through an AMQP broker. In OpenAMQ we got performance up to 300K messages/second.

    AMQP was designed for speed (e.g. it does not unpack messages in order to route them) but ZeroMQ is simply better designed in key ways. E.g. it removes a hop by connecting nodes without a broker; it does better asynchronous I/O than any of the AMQP client stacks; it does more aggressive message batching. Perhaps 60% of the time spent building ZeroMQ went into performance tuning. It was very hard work. It's not faster by accident.

    One thing I'd like to do, but am too busy, is to recreate an AMQP-like broker on top of ZeroMQ. There is a first layer here: http://rfc.zeromq.org/spec:15. The whole stack would work somewhat like RestMS, with transport and semantics separated into two layers. It would provide much the same functionality as AMQP/0.9.1 (and be semantically interoperable) but significantly faster.

    0 讨论(0)
  • 2020-12-12 10:07

    I've tested c++/qpid

    I sent 50000 messages per second between two diferent machines for a long time with no queuing.

    I didn't use a fanout, just a simple exchange (non persistent messages)

    Are you using persistent messages? Are you parsing the messages?

    I suppose not, since 0MQ doesn't have message structs.

    If the broker is mainly idle, you probably haven't configured the prefetch on sender and receptor. This is very important to send many messages.

    0 讨论(0)
  • 2020-12-12 10:10

    Try to configure prefetch on sender and receptor with a value like 100. Prefetching just sender is not enough

    0 讨论(0)
提交回复
热议问题