[译] Fast RTPS与Cyclone DDS与OpenSplice DDS对比测试

比较了三种情况下的延迟和吞吐量：双主机，进程间 和 进程内。

在所有测试的情况下，Fast RTPS所提供的等待时间更短，吞吐量更高。

测试环境

系统为：Ubuntu 18.04.2 LTS bionic

内核为：Linux 4.15.0-64通用内核

机器的规格为：

架构：x86_64

处理器：8

每个核心线程数：2

型号名称：Intel（R）Xeon（R）CPU E3-1230 v6 @ 3.50GHz

DDS中间件版本：2019年9月17日在主仓库上的最新版本

Fast RTPS 1.9.x：010ac53

Cyclone DDS ：801c4b1

OpenSplice DDS：v6.9

对比测试项 （延迟、吞吐量）

延迟测试

测量延迟方法：

在网络计算中，延迟时间定义为对消息在系统上花费的时间的度量。也就是说，衡量消息自发送方发送以来经过的时间直到被接收方接收到为止 。为了避免发布者和订阅者所在的系统之间的时钟同步问题，一种近似的延迟方法是通过往返时间。在这种情况下，发布者发送一条消息，并等待订阅者将其发送回（类似于乒乓范式），从而测量发布者的发送操作与发布者的接收操作之间的经过时间。为了获得等待时间的近似值，将测得的往返时间除以2。

image.png

统一测试环境和配置：

1. 配置了相同的DDS服务质量（QoS）参数。（由于OpenSplice可靠性是不可配置的，因需要将代码补丁应用于OpenSplice示例。）

2. 使用UDPv4作为传输层进行的。

3. 是在同一台计算机（本地主机）上以及通过以太网连接的独立计算机（双主机）中运行发送方和读取方的。

4. 针对11种不同的消息大小进行比较：16、32、64、128、256、512、1024、2048、4096、8192和16384字节。

为了执行测试，每种消息大小都会发送10000条消息，并提取最小和平均测量值。

DDS QoS 的配置如下：

可靠性(Reliability)：RELIABLE

历史记录类型（History kind）：KEEP_LAST

历史深度(History depth)：1

持久性(Durability)：VOLATILE

• 本地主机比较-进程间：

  
  
  image.png

-本地主机比较-进程内：

image.png

• 双主机比较：

image.png

结论：本地主机和双主机的比较都显示了Fast-RTPS与其他两个实现之间的明显区别。可以看出，Fast-RPTS的平均延迟始终小于其他实现的最小值。重要的是要注意，Fast-RTPS延迟对于更多的有效负载是稳定的，与CycloneDDS或OpenSplice相比，在较大的有效负载中以较小的增加速率增加。在这种情况下，还值得注意的是，尤其是在双主机情况下，Fast-RTPS均值更紧密地遵循最小值，这意味着最小值和最大值之间的差异始终都较小（均值周围的分布较窄）。

吞吐量测试

测量吞吐量方法:

在网络计算中，吞吐量定义为每单位时间可以通过系统发送/接收的信息量的度量，即每秒测量多少比特穿越系统的度量。正常的测量操作是使发布者在一定时间（ burst interval）内发送大量消息。在完成发送之后，如果操作花费的时间少于突发间隔（ burst interval），则发布者将处于休息状态，直到间隔完全过去（否则，发布者将无法休息）。执行此操作，一直到测试时间。在接收方，接收信息，记录接收到第一条消息的时间，并对到达的每条消息进行计数。测试完成后，接收方可以计算接收采样率。知道每个消息的大小（以位为单位），吞吐量就是采样率乘以消息大小的乘积。下图说明了此过程。

image.png

统一测试环境和配置：

通过使用以下工具进行测试比较：

• Fast-RTPS 的ThroughputTest

• CycloneDDS的ThroughputPublisher 和ThroughputSubscriber 示例

• OpenSplice的Throughput/publisher and Throughput/subscriber 示例。

1. 配置相同的DDS服务质量（QoS）参数。

2. 使用UDPv4作为传输层进行的。

3. 在同一台计算机（本地主机）上以及通过以太网连接的独立计算机（双主机）中运行发送方和读取方的。

4. 在本地主机上对11种不同的消息大小进行测试：16、32、64、128、256、512、1024、2048、4096、8192和16384字节。

5. 在双主机环境中针对13种不同的消息大小进行测试：16、32、64、128、256、512、1024、2048、4096、8192、16384字节，32768和64000字节。

为了执行实验，使用了100、200、500、1000、10000、20000、30000、40000和50000条消息的需求。

为了执行实验，使用了0、10、20、30、40、50、60、70、80、90和100 ms的突发间隔（burst intervals）。

一些内核的缓冲区已配置为以最大化信息流，

net.core.rmem_default = 21299200

net.core.rmem_max = 21299200

net.ipv4.udp_mem = 102400 873800 21299200

net.core.netdev_max_backlog = 30000

使用以下软件版本进行了测试：

Fast-RTPS commit：0bcafbde1c6fa3ef7285819980f932df910dba61

CycloneDDS commit： aa5236dea46b82e6db26a0c87b90cedeca465524

OpenSplice version：v6.9

DDS QoS 的配置如下：

可靠性(Reliability)：RELIABLE

历史记录类型（History kind）：KEEP_ALL

持久性(Durability)：VOLATILE

• 本地主机比较-进程间

  
  
  image.png

• 双主机比较

  
  
  image.png

结论 ：本地主机比较显示了Fast-RTPS与其他两个实现之间的明显区别。可以看出，Fast-RPTS的吞吐量是每个有效载荷最高的。关于双主机比较，Fast-RTPS和CycloneDDS都显示了几乎等效的吞吐量，最高有效负载为256字节，但是大于256字节后两者之间的差异变得很大，可以看出Fast-RTPS 更出色。（？但是什么在2048->4096->8192会掉下来？）

最后： 这表明Fast-RTPS是在所有测试情况下最快的消息传递实现。此外，在处理消息传递延迟时，Fast-RTPS是最一致的一种。这一切都意味着，使用Fast-RTPS，经历的延迟是最短的，并且始终保持几乎相同。

整理翻译自：https://www.eprosima.com/index.php/resources-all/performance/fast-rtps-vs-cyclone-dds