ZeroMQ、RabbitMQ 和 Apache Qpid 之间的性能比较答案

【问题标题】：Performance comparison between ZeroMQ, RabbitMQ and Apache QpidZeroMQ、RabbitMQ 和 Apache Qpid 之间的性能比较
【发布时间】：2011-12-16 19:19:20
【问题描述】：

我的应用程序需要高性能消息总线，因此我正在评估ZeroMQ、RabbitMQ 和Apache Qpid 的性能。为了测量性能，我正在运行一个测试程序，该程序使用其中一个消息队列实现发布 10,000 条消息，并在同一台机器上运行另一个进程来使用这 10,000 条消息。然后我记录发布的第一条消息和收到的最后一条消息之间的时间差。

以下是我用于比较的设置。

RabbitMQ：我使用了“扇出”类型的交换和默认配置的队列。我使用了 RabbitMQ C 客户端库。
ZeroMQ：我的发布者使用ZMQ_PUSH 套接字发布到tcp://localhost:port1，我的代理监听tcp://localhost:port1 并将消息重新发送到tcp://localhost:port2，我的消费者使用ZMQ_PULL 套接字监听tcp://localhost:port2。我在ZeroMQ 中使用代理而不是点对点通信，以使性能比较与使用代理的其他消息队列实现公平。
Qpid C++ 消息代理：我使用了“扇出”类型的交换和默认配置的队列。我使用了 Qpid C++ 客户端库。

以下是性能结果：

RabbitMQ：接收10000条消息大约需要1秒。
ZeroMQ：接收 10000 条消息大约需要 15 毫秒。
Qpid：接收10000条消息大约需要4秒。

问题：

有没有人在消息队列之间进行过类似的性能比较？然后，我想将我的结果与您的结果进行比较。
有什么方法可以调整RabbitMQ 或Qpid 以使其性能更好？

注意：

测试是在分配了两个处理器的虚拟机上完成的。不同硬件的结果可能会有所不同，但我主要对 MQ 产品的相对性能感兴趣。

【问题讨论】：

几个月前我进行了简单的测试，结果相似。我注意到系统在使用 RabbitMQ 或 Qpid 时非常空闲。我觉得一定有什么地方不对劲。
"RabbitMQ：接收 10,000 条消息大约需要 12 秒。" -- 在我们自己的测试中，我们经常看到每个 CPU 每秒 20-25,000 个入口。因此，您做错了什么，或者使用了慢速客户端。您是否尝试通过电子邮件向 rabbitmq-discuss 发送问题？
这是一个很好的比较，日期为 2013 年 4 月 10 日：x-aeon.com/wp/2013/04/10/…
RabbitMQ、Kafka、HornetQ、ActiveMQ、SQS 和 Mongo 性能比较的更新版本现在在这里：softwaremill.com/mqperf
你做这个测试时每条消息是多少字节？

标签： message-queue rabbitmq zeromq qpid

【解决方案1】：

我已经测试过 c++/qpid

我很长时间在两台不同的机器之间每秒发送 50000 条消息，没有排队。

我没有使用扇出，只是一个简单的交换（非持久消息）

您是否使用持久性消息？你在解析消息吗？

我想没有，因为 0MQ 没有消息结构。

如果代理主要是空闲的，您可能没有在发送方和接收方上配置预取。这对于发送许多消息非常重要。

【讨论】：

我使用的是非持久队列，我不解析消息，实际上我使用相同的代码为所有三个队列实验生成消息。将交换类型更改为直接对性能没有影响。同样在使用发送方流量控制（api sender.SetCapaclity(8)）之后，时间变得更糟了。如果没有发送方流量控制，队列似乎会无限增长。在测量时间的时候，你有没有等到收到所有消息，队列完全排空？
我发现 qpid-perftest 程序正在使用 Qpid 的“旧消息 API”。在我的测试中，切换到旧的 API 后性能提高了 10 倍。

【解决方案2】：

嗯，当然 ZeroMQ 会更快，它被设计为具有其他两个提供的基于代理的功能，并且没有很多。 ZeroMQ site 很好地比较了代理与无代理消息传递以及两者的优缺点。

RabbitMQ Blog:

RabbitMQ 和 0MQ 专注于消息传递的不同方面。 0MQ 更加关注消息是如何通过网络传输的。另一方面，RabbitMQ 专注于如何存储、过滤和监控消息。

（我也喜欢上面的 RabbitMQ 帖子，因为它还谈到了将 ZeroMQ 与 RabbitMQ 一起使用）

所以，我想说的是，您应该决定最适合您要求的技术。如果唯一的要求是速度，ZeroMQ。但是，如果您需要其他方面，例如消息的持久性、过滤、监控、故障转移等，那么您就需要开始考虑 RabbitMQ 和 Qpid。

【讨论】：

ZeroMQ 没有代理。您将代理设计为应用程序整体设计的一部分，并且您的代理在 zeromq 上侦听，根据目的地路由消息。 ZeroMQ 只做一项工作并且做得非常好：消息队列。有 Malamute，它是 ZeroMQ 人员为 ZeroMQ 设计的代理实现，但它不是开箱即用的 ZeroMQ 的一部分。您可以将它与 ZeroMQ 一起安装在它自己的进程中或专门用于消息代理的单独盒子上。这是它自己的项目。 github.com/zeromq/malamute
是的，我说它没有经纪人，并链接到经纪人与无经纪人的文章。那不是很清楚吗？另外，当我在 2011 年发布这个答案时，没有雪橇犬，它出现在 2014 年 10 月

【解决方案3】：

尝试在发送者和接收者上配置预取值，例如 100。仅预取发送者是不够的

【讨论】：

对于 qpid，我的印象是 Receiver.setCapacity(100) 设置了接收器的预取。这样做之后，使用“新 qpid api”的代码的性能提高了 10 倍，并且性能类似于 Qpid 旧消息 Api。我已经用结果更新了帖子。然而，Qpid 似乎仍然比 rabbitmq 慢 4 倍。

【解决方案4】：

RabbitMQ 可能正在对这些消息进行持久化。我认为您需要在消息中设置消息优先级或其他选项以不进行持久性。届时性能将提高 10 倍。您应该期望至少 100K 消息/秒通过 AMQP 代理。在 OpenAMQ 中，我们获得了高达 300K 消息/秒的性能。

AMQP 是为提高速度而设计的（例如，它不会为了路由消息而解包消息），但 ZeroMQ 只是在关键方面设计得更好。例如。它通过在没有代理的情况下连接节点来移除一个跃点；与任何 AMQP 客户端堆栈相比，它的异步 I/O 性能更好；它进行更积极的消息批处理。构建 ZeroMQ 所花费的时间可能有 60% 用于性能调优。这是非常艰苦的工作。它不是偶然更快。

我想做但太忙的一件事是在 ZeroMQ 之上重新创建一个类似 AMQP 的代理。这里有第一层：http://rfc.zeromq.org/spec:15。整个堆栈的工作方式有点像 RestMS，传输和语义分为两层。它将提供与 AMQP/0.9.1 大致相同的功能（并且在语义上可互操作），但速度要快得多。

【讨论】：

我们将继续使用rabbitmq，直到有人提出比@pieter btw 更好的解决方案。它让我想起了伟大的专利故事[1]。 [1]youtube.com/watch?v=5QqbDyZ8Eu4
RIP 伙伴，你做了一些很棒的东西

【解决方案5】：

我们在站点http://www.udaparts.com/document/articles/fastsocketpro.htm 上将 RabbitMQ 与我们的 SocketPro (http://www.udaparts.com/) 持久消息队列与所有源代码进行了比较。以下是我们为 RabbitMQ 获得的结果：

同一台机器入队和出队：

“世界你好”--
入队：每秒 30000 条消息；
出队：每秒 7000 条消息。

1024 字节的文本 --
入队：每秒 11000 条消息；
出队：每秒 7000 条消息。

10 * 1024 字节的文本 --
入队：每秒 4000 条消息；
出队：每秒 4000 条消息。

网络带宽为 100 mbps 的跨机入队和出队：

“世界你好”--
入队：每秒 28000 条消息；
出队：每秒 1900 条消息。

1024 字节的文本 --
入队：每秒 8000 条消息；
出队：每秒 1000 条消息。

10 * 1024 字节的文本 --
入队：每秒 800 条消息；
出队：每秒 700 条消息。

【讨论】：

【解决方案6】：

我在 ZeroMQ 中使用代理而不是点对点通信，以使性能比较与使用代理的其他消息队列实现公平。

不确定您为什么要这样做 - 如果您只关心性能，那么就没有必要让竞争环境保持水平。如果您不关心持久性、过滤等，那为什么要付出代价呢？

我也对在 VM 上运行基准测试持怀疑态度——有很多额外的层会以不明显的方式影响结果。（当然，除非您打算在虚拟机上运行真实系统，在这种情况下这是一种非常有效的方法）。

【讨论】：

【解决方案7】：

我们开发了一个基于 ZeroMQ 的开源消息总线 - 我们最初这样做是为了替换 Qpid。它是无代理的，所以这不是一个完全公平的比较，但它提供了与代理解决方案相同的功能。

我们的主要性能数据是两台机器之间每秒 140K msgs，但您可以在此处查看更多详细信息：https://github.com/Abc-Arbitrage/Zebus/wiki/Performance

【讨论】：