湖南省房屋和城乡建设部网站,有了网站怎么做app吗,国家企业信息公示系统官网官,哪个网站做自媒体比较好文章目录 0. 引言1. 目标#xff1a;ZeroMQ与Fast-DDS性能对比2. ZeroMQ vs Fast-DDS - 延迟基准测试2.1 一对一发布-订阅延迟2.2 一对多发布-订阅延迟 3. ZeroMQ vs Fast-DDS - 吞吐量基准测试4. 方法论5. 结论6. 参考 0. 引言 高要求的分布式系统催生了对轻量级且高性能中间… 文章目录 0. 引言1. 目标ZeroMQ与Fast-DDS性能对比2. ZeroMQ vs Fast-DDS - 延迟基准测试2.1 一对一发布-订阅延迟2.2 一对多发布-订阅延迟 3. ZeroMQ vs Fast-DDS - 吞吐量基准测试4. 方法论5. 结论6. 参考 0. 引言 高要求的分布式系统催生了对轻量级且高性能中间件的需求。在现有的选项中ZeroMQ 和 Fast-DDS 是高性能的异步中间件采用发布-订阅模式。 主要优点包括 性能更好的延迟和吞吐量。数据在可用时立即发送。高度解耦无需周期性请求数据订阅者只需声明对数据更新的兴趣即可。 ZeroMQ 是一种消息中间件不需要消息代理并实现了多种通信模式包括发布-订阅和请求-响应。消息的序列化和反序列化需要用户自己实现。其API类似于套接字库。 Fast-DDS 是实时发布订阅协议RTPS的高性能实现提供了简单的发布-订阅API。该产品通过从接口定义语言IDL生成代码的方式提供序列化支持并包含一个超快速的序列化库eProsima FastCDR。 1. 目标ZeroMQ与Fast-DDS性能对比 本次测试的目标是测量并比较在使用发布-订阅模式下Fast-DDS与ZeroMQ的延迟和吞吐量。Fast-DDS使用eProsima FastCDR进行数据序列化这是一款非常快速的序列化引擎。 需要考虑的差异 Fast-DDS和ZeroMQ之间有一些差异需要分析。 传输协议Fast-DDS支持TCP和UDP而默认使用TCPZeroMQ使用TCP。Fast-DDS的UDP模式包含自己的ACK/NACK可靠性协议支持单播和多播。协议头另一个直接影响性能的重要差异是每个协议的头部。RTPS是一个更加多功能的协议设计用于在无可靠性的协议上实现。它还具备许多其他功能如键控主题、顺序传递等因此其头部更大。从测试结果中可以看到ZeroMQ在处理非常小的消息时稍微优于Fast-DDS这很可能是由于较小的头部导致的。节点发现发现机制也是一个需要考虑的因素。Fast-DDS带有内置的端点发现机制。用户只需指定主题名称和数据类型如果QoS兼容中间件会自动匹配发布者和订阅者这使得设置和配置更加简单。然而ZeroMQ没有这样的机制用户需要手动设置发布者和订阅者的IP地址以实现通信。 2. ZeroMQ vs Fast-DDS - 延迟基准测试 2.1 一对一发布-订阅延迟 一对一订阅延迟的对比见下图 在小消息大小的情况下ZeroMQ的延迟略优。然而随着消息大小的增加Fast-DDS的延迟优于ZeroMQ。两者都表现出相似的线性行为但Fast-DDS的斜率更小。 如前所述ZeroMQ在消息大小在16到128字节之间时表现出更小的延迟。这种现象最可能的解释是ØMQ消息的头部比RTPS消息的头部更小。随着消息大小的增加头部大小的重要性下降因为它在传输数据中所占比例变小。 2.2 一对多发布-订阅延迟 相同的测试也在有三个订阅者的场景下进行 在小消息大小的情况下ZeroMQ和Fast-DDS的延迟非常相似。随着消息大小的增加使用Fast-DDS和多播广播的优势变得更加明显。对于16K字节大小的消息延迟差异可高达200微秒。 在这种情况下ZeroMQ的头部较小的优势因需要向每个订阅者发送相同数据而被抵消。可以看到在小消息大小情况下两个实现的延迟值非常相似这增强了Fast-DDS相对于ZeroMQ的竞争力。随着订阅者数量的增加ZeroMQ的延迟值可能会明显增加而Fast-DDS的增长则更缓慢。 3. ZeroMQ vs Fast-DDS - 吞吐量基准测试 下图展示了ZeroMQ与Fast-DDS之间的吞吐量对比 此图表明ZeroMQ在处理较小消息大小时能实现更高的吞吐量。这是因为ZeroMQ使用的是TCP这是一种优化了吞吐量的流协议而RTPS主要是为实时性能而设计的使用了无连接的UDP。 然而随着消息大小的增加Fast-DDS开始表现出更高的吞吐量并最终超过ZeroMQ。这是因为Fast-DDS的序列化和传输算法在大消息的情况下比ZeroMQ更为有效。对于高负载场景Fast-DDS成为更优的选择。 4. 方法论 延迟 延迟通常定义为消息穿越系统所需的时间。在基于数据包的网络中延迟通常被测量为单程延迟从源节点发送数据包到目的节点接收数据包的时间或往返延迟从源节点到目的节点的时间加上从目的节点返回到源节点的时间。后者更常用因为它可以从一个点测量。 在RTPS通信交换中延迟可以定义为发布者序列化并发送数据消息所需的时间加上匹配的订阅者接收并反序列化消息所需的时间。应用之前提到的往返概念往返延迟可以定义为消息由发布者发送订阅者接收并发送回发布者的时间。例如在下图中往返时间将是T2-T1延迟为(T2-T1)/2。 在多个订阅者场景中测量延迟采用类似的过程。在这种情况下发布者将数据发送给两个订阅者但只有一个对消息做出响应。类似地延迟也计算为(T2-T1)/2。 吞吐量 在通信网络中吞吐量通常定义为通过通信通道成功传输消息的速率。吞吐量通常以字节每秒来表示。有多种方法可以测量通信网络的吞吐量。最常见的方法是发送一个大文件或多个较小文件然后测量将其传输到网络的另一个点所需的时间之后将数据量除以传输所需的时间。 在RTPS通信的情况下可以通过在一定时间内发送一组消息来测量吞吐量并获取传输数据的总大小。然而为了获得最大吞吐量值必须尝试不同的消息需求D - 连续发送的消息数量以找到最佳值即最大化发布者的可用发送通道而不会导致订阅者接收队列溢出造成数据包丢失。下面的图表展示了进行此测试的过程 当然吞吐量可以在发布者端发送了多少数据和订阅者端接收了多少数据进行测量。如果没有数据包丢失两个值将非常相似值之间的微小差异将由时间测量的差异引起。然而如果数据包丢失则吞吐量值将根据不同的端点而有所不同。为了建立一个可靠的测量规则我们将假设每个消息大小的最大吞吐量为在发布者端测量的值前提是订阅者端没有数据包丢失。 5. 结论 两者均展示了非常优越的性能但在特定情况下有所不同 小消息ZeroMQ通常在处理小消息如控制指令、状态更新等时表现更好特别是在需要高吞吐量的情况下。大消息与多订阅者场景Fast-DDS在处理大消息时具有优势特别是在多订阅者场景中其多播支持表现出色。它还具有更加灵活且自动化的节点发现和匹配机制降低了用户配置的复杂性。 最终选择哪种中间件取决于你的系统的具体需求是小消息和高吞吐量还是大消息和更好的多播支持。 6. 参考 本文内容数据引用自zmq-vs-eprosima-fast-rtps,原文已不能访问。本文是通过eprosima-zmq-vs-eprosima-fast-rtps访问到的。