Zenoh、MQTT、Kafka和DDS的性能比较

序言

这一期的博客由著名的台湾大学（NTU）的一组研究人员撰写。该团队在R2X和V2X研发项目中使用Zenoh已经有一段时间了，最近对我们的Blue Dragon 协议、MQTT、Kafka和DDS进行了有趣的性能比较。我要代表Zenoh社区感谢台湾大学的团队，因为这次评估回答了我们经常被问到的几个问题。

-kydos

介绍

高性能一直是泽诺的主要目标之一。虽然每个版本都提供了Zenoh的性能（请参阅此处、此处和此处），但到目前为止，还没有将Zenoh与其他技术进行比较的性能评估。然而，这是在 Zenoh 的 Discord 和Github上很常被问到的问题。在这个博客中，我们将基台湾大学所发表的这篇论文，并进一步做出探讨和分析。

通信模型

MQTT和Kafka采用了一种代理通信模型，其中每条消息都必须通过一个代理。不同的是，DDS采用了对等通信模型，在该模型中，消息在发布者和订阅者之间直接交换，而不需要任何中间人。Zenoh同时支持代理和对等通信模式，以及路由基础设施模式。图1展示了具有混合拓扑的模型，其中Mesh和Clique是对等模型。有关详细信息，请参阅各种部署模型。为了与MQTT、Kafka和DDS进行公平的比较，Zenoh中同时使用了代理和对等模式。

图 1 杰诺提供的拓扑结构

测试的性能指标

对于此性能评估，我们感兴趣的是评估两个关键性能指标，即吞吐量和延迟。图2显示了吞吐量测量的通信图。对于Zenoh、MQTT和Kafka之间的比较，所有数据都通过“代理”或“Zenoh 路由器”流到订阅者。对于Zenoh对等模式和DDS测试，数据直接从发布者传递到订阅者。

图 2 吞吐量测试配置图

图3显示了延迟测量的通信图。与吞吐量测试类似，对于MQTT、Kafka和Zenoh客户端模式，消息将由代理或路由器转发，对于Zenoh对等模式和DDS，数据将直接在ping和pong节点之间传递。

图 2 延迟测试配置图

试验台配置

实验准备了两种场景：在一台单机上和在通过以太网连接的多台机器上。对于多机器场景，测试的程序和代理（或Zenoh路由器）将在不同的机器上运行。表1显示了每台使用过的机器的配置。

表1试验机配置

所有Zenoh、DDS、MQTT和Kafka的测试过程都是相同的。它们的版本和设置如下所述。这些程序是根据准确测量指南中的建议设计的。所有的基准测试程序都可以在Zenoh性能测试项目下找到。

对于Zenoh，测试程序使用0.7.0-rc 版本，Zenoh 路由器zenohd 可按照本指南构建。 其可靠性被设为 “可靠”，发布方的拥塞控制选项被设为 “阻止”。 对于延迟测量，其可靠性被设置为 “BestEffort”，以便与 Kafka 和 MQTT 的行为保持一致。

对于MQTT，测试程序使用Eclipse Mosquitto 2.0.15 版本。 MQTT客户端是用Eclipse Paho MQTT C 客户端库 v.1.3.11 实现的。对于所有MQTT客户端，通信QoS级别都设置为0以实现最佳性能。

对于Kafka，测试程序中的代理端和客戶端分別使用了官方的 3.2.1版和 rdkafka 库 0.28.0版。

为了获得更好的结果，根据在线文档和实际实验的建议，选择了以下参数：吞吐量为linger.ms=0，吞吐量为batch.size=400KB，延迟为1；compression.type=none，acks=0，fetch.min.bytes=1（仅用于延迟测试）。

对于DDS，测试程序使用Eclipse Cyclone DDS作为目标实现。它们基于官方DDS示例。对于可靠性QoS，采用了RELABLE。对于历史QoS，KEEP_LAST用于延迟测试，KEEP_ALL用于吞吐量测试。

吞吐量比较

在吞吐量测试中，发布程序背靠背地发布消息。订阅同一主题的使用者程序收集一组消息并计算消息速率（msg/s）。对于每个有效载荷大小，该过程将重复多次，并且从样本中选择中间数作为结果，其中超过第1和第99百分位数的样本将视为异常值并从中排除。同样的过程也适用于Zenoh、Cyclone DDS（以下简称为DDS）、MQTT和Kafka。比特率（bit/s）也是基于消息速率和有效载荷大小来计算的。此外，iperf实用程序还用于测量两个对等点之间应用层的理想数据速率。为查看吞吐量的趋势，从8字节到512MB的各种有效载荷大小都有被测试。我們在下面的图表中Y轴的对数刻度，分別显示了消息速率和比特率。统计数据可以在点击此处。找到。以下各段将报告其中一些数字，以供讨论。

图 4 以毫秒/秒为单位的单机方案吞吐量数据

图4显示了单机场景的结果。从图中可以看出，对于较小的有效载荷大小，Zenoh可以达到4M msg/s以上。在Zenoh的两条线中，对等模式（由Zenoh P2P表示）比客户端模式（由Zenoh brokered表示）提供了更好的结果，因为数据传输不需要由Zenoh路由器中继。DDS虽然速度较慢，但相对接近Zenoh，仍然可以达到2M msg/s。请注意在图表中，Y轴是日志刻度。

至于Kafka，对于小于2KB的有效载荷大小，它保持56K到63K msg/s之间的稳定消息速率，并开始降低，直到最后一个数据被成功测量出512KB的有效载荷尺寸。另一方面，MQTT在负载大小为32KB之前，33K到38K msg/s之间的吞吐量稍低。然而它随后开始大幅减少，并显示出最差的性能数字。尽管与Kafka相比，它支持更大的有效负载大小。然而原则上Kafka应该能够支持更多的有效负载大小。观察到的限制背后的原因是，我们使用的Kafka绑定无法将消息大小扩展到1MB以上。

图 5 以比特/秒为单位的单机方案吞吐量数据

图5提供了以比特每秒（bit/s或bps）为单位的吞吐量。它表明对等于或大于4KB的有效载荷大小，Zenoh开始向iperf测量的理想吞吐量饱和（76Gpbs）。对等模式的Zenoh P2P最高可达67Gbps。对于DDS，实现的最高吞吐量约为26Gpbs。当有效负载大小大于16KB时，Kafka似乎在大约4~5Gbps时饱和。对于MQTT，它在32  KB的有效负载大小下可达到约9 Gbps。MQTT的性能下降现象在测试中不断出现。这背后的原因仍然未知，未来值得进一步研究。

总体在这种单机场景中，以比特率数字进行吞吐量比较，考虑到从Zenoh、DDS、Kafka和MQTT获得的最佳数值，Zenoh对等模式在8字节的有效负载大小下，实现了比DDS的65x和Kafka与MQTT的130x，高约2倍的性能，。Zenoh在8KB时实现了峰值性能，吞吐量是DDS的4倍以上，是Kafka的24倍，是MQTT的27倍。最后，对于32KB的有效负载，Zenoh实现了比DDS高2倍多的吞吐量，比MQTT高5倍，比Kafka高10倍。

100 Gb以太网上多台机器的吞吐量如图6和图7所示。我们将在这里主要关注比特率结果。

图 6 以毫秒/秒为单位的多机方案吞吐量数据

图 7 多机方案的吞吐量数据（比特/秒

在图中，iperf显示目标网络的理想吞吐量为44Gpbs。Zenoh代理的最大比特率约为34Gbps，Zenoh P2P的最大比特速率约为50Gbps。对于Cyclone DDS，其吞吐量排名仍保持在排行榜的第三位，为14Gbps。另一方面，MQTT的比特率可以在32KB的有效负载大小下达到9Gbps，然后下降，类似于单机场景。对于Kafka来说，它的最佳比特率是5Gbps，有效负载大小也是32KB。

作为比较的总结，从多机场景中观察到的结果与单机结果保持着相似的性能趋势，表明Zenoh的性能改进比DDS、Kafka和MQTT高出几到几十倍。

延迟比较

在延迟测试中，ping程序发布ping消息，并且pong程序在接收到ping时用相同的消息进行回复。测试的有效载荷大小固定为64字节（与ICMP回显/回复对齐），并且以背靠背的方式执行测试，以减少底层操作系统引起的进程调度和上下文切换的影响。延迟被定义为覆盖ping和pong操作的中值往返时间的一半。类似地，我们去除了超过第1和第99个百分位数的异常值。统计数据也可以在这里找到。表2显示了测试结果。并且我们使用Linux Ping 程序作为可达到最小延迟的基线。

表2 单机和多机情况下的延迟数据，单位为µs（微秒）

对于单机环境，通过ping获得的理想延迟值为1µs。MQTT和Kafka的延迟分别为73µs和27µs。至于Zenoh，虽然Zenoh代理的客户端模式的延迟为21µs，主要是由于通过中间人路由数据，但Zenoh P2P显示它可以进一步降低到10µs。对于Cyclone DDS，延迟甚至低于Zenoh，可达到8µs。原因是它使用UDP Multicast。尽管Zenoh目前还没有实现相同的数据传输，但Zenoh的微控制器实现——Zenoh pico——已经实现了这一点。因此如上Zenoh pico所示，它的延迟可以來到5µs，甚至低于Cyclone DDS，主要是因为Zenoh协议及其实现可以比OMG DDSI-RTPS协议（由所有符合DDS的工具实现）更轻、更高效。

对于具有100Gb以太网的真实网络上的多机场景，Zenoh代理的延迟约为41µs，对等模式下的Zenoh P2P数量为16µs，低于Kafka的81µs、MQTT的45µs和Cyclone DDS的37µs。对于Zenoh pico，它在13µs时仍然是最好的，最接近ping实用程序在7µs时获得的基线。

总体来说，Zenoh的延迟较低。与MQTT和Kafka（以及用于多机场景的DDS）相比，具有默认对等模式的Zenoh具有最短的延迟。当Zenoh支持UDP Multicaset传输时，正如Zenoh pico所显示的结果，预计Zenoh可以实现所有软件中最低的数值。

结论

在这个博客中，我们比较了Zenoh、MQTT、Kafka和DDS的性能。Zenoh的表现一直优于MQTT和Kafka。结果表明，由于Zenoh的实现中嵌入了低开销设计和多种优化技术，Zenoh相对更接近经典基线工具iperf和ping从应用层获得的吞吐量和延迟评估的理想数值。

在我们的评估中，当使用默认对等模式时，Zenoh在100GbE网络的单机和多机测试里，分别实现了高达67Gbps和51Gbps的吞吐量。它可以在MQTT和Kafka的基础上提高1~2个数量级，并可以使DDS的吞吐量翻倍。值得注意的是，Cyclone DDS在单机场景的延迟测试中表现最好，因为它使用了UDP Multicast传输机制。然而当Zenoh的微控制器实现Zenoh pico也实现了UDP Multicas传输时，它在所有情况下都达到了最低的延迟。此功能稍后将得到所有Zenoh实现的支持。

Zenoh的目标是提供一个具有无与伦比的性能和可扩展性的下一代通信框架。除了令人难以置信的性能外，Zenoh还是颇为简单的API和颇短学习曲线的技术。我们相信，Zenoh是工业、物联网、机器人和汽车应用程序的优先选择，可以无缝支持云到边缘和物到物的连续性。

希望您喜欢，

– William , Circle 和 Jerry

1. 在arXiv版本中，没有显示平均数（带标准差），而是在这个博客中使用中值来增加比较的公平性。