比较了三种情况下的延迟和吞吐量：双主机，进程间 和 进程内。
在所有测试的情况下，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。
统一测试环境和配置：
配置了相同的DDS服务质量（QoS）参数。（由于OpenSplice可靠性是不可配置的，因需要将代码补丁应用于OpenSplice示例。）
使用UDPv4作为传输层进行的。
是在同一台计算机（本地主机）上以及通过以太网连接的独立计算机（双主机）中运行发送方和读取方的。
针对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
-本地主机比较-进程内：
结论：本地主机和双主机的比较都显示了Fast-RTPS与其他两个实现之间的明显区别。可以看出，Fast-RPTS的平均延迟始终小于其他实现的最小值。重要的是要注意，Fast-RTPS延迟对于更多的有效负载是稳定的，与CycloneDDS或OpenSplice相比，在较大的有效负载中以较小的增加速率增加。在这种情况下，还值得注意的是，尤其是在双主机情况下，Fast-RTPS均值更紧密地遵循最小值，这意味着最小值和最大值之间的差异始终都较小（均值周围的分布较窄）。
吞吐量测试
测量吞吐量方法:
在网络计算中，吞吐量定义为每单位时间可以通过系统发送/接收的信息量的度量，即每秒测量多少比特穿越系统的度量。正常的测量操作是使发布者在一定时间（ burst interval）内发送大量消息。在完成发送之后，如果操作花费的时间少于突发间隔（ burst interval），则发布者将处于休息状态，直到间隔完全过去（否则，发布者将无法休息）。执行此操作，一直到测试时间。在接收方，接收信息，记录接收到第一条消息的时间，并对到达的每条消息进行计数。测试完成后，接收方可以计算接收采样率。知道每个消息的大小（以位为单位），吞吐量就是采样率乘以消息大小的乘积。下图说明了此过程。
统一测试环境和配置：
通过使用以下工具进行测试比较：
Fast-RTPS 的ThroughputTest
CycloneDDS的ThroughputPublisher 和ThroughputSubscriber 示例
OpenSplice的Throughput/publisher and Throughput/subscriber 示例。
配置相同的DDS服务质量（QoS）参数。
使用UDPv4作为传输层进行的。
在同一台计算机（本地主机）上以及通过以太网连接的独立计算机（双主机）中运行发送方和读取方的。
在本地主机上对11种不同的消息大小进行测试：16、32、64、128、256、512、1024、2048、4096、8192和16384字节。
在双主机环境中针对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
