运输基准的不同结果

Question

我为Aeron的演示做了一些基准测试，但我发现，如果我对相同的传输使用不同的工具，我得到的结果略有不同。

例如，如果我使用HDR直方图，我得到的结果与维护人员在测试中得到的数字一致：

• 我的代码https://github.com/easy-logic/transport-benchmarks/blob/master/aeron-ping/src/main/java/io/easylogic/benchmarks/aeronpingbenchmarkhdrhistogram.java
• 结果https://github.com/easy-logic/transport-benchmarks/blob/master/results/aeron-docker-hdr.txt

此外，我还尝试了另一个很酷的java基准库-JLBH

但结果让我有点迷惑...

首先，我得到了2个不同版本的基准：

• 单线程https://github.com/easy-logic/transport-benchmarks/blob/master/aeron-ping/src/main/java/html" target="_blank">io/easylogic/benchmarks/aeronpingbenchmarkjlbhsinglethread.java
• 线程发布者/线程接收者https://github.com/easy-logic/transport-benchmarks/blob/master/aeron-ping/src/main/java/io/easylogic/benchmarks/aeronpingbenchmarkjlbhseparatethread.java

JLBH似乎鼓励为侦听器使用另一个线程，至少在这样一些设置（如吞吐量）更有意义，并且初始预热会打印一些统计数据。但我可能会大错特错，如果我错了，请纠正我。

但更重要的是，这些基准测试的结果完全不同，与我在HDR中看到的结果不一致：

• 单线程https://github.com/easy-logic/transport-benchmarks/blob/master/results/aeron-docker-jlbh-sigle-thread.txt
• 线程发布者/线程接收者https://github.com/easy-logic/transport-benchmarks/blob/master/results/aeron-docker-jlbh-separate-threads.txt

我很有可能在某个地方搞砸了，但目前为止，所有3个基准测试看起来或多或少与我相似，只是使用了不同的工具集。

非常感谢！

附注。

如果有人想自己尝试，您只需运行这个脚本https://github.com/easy-logic/transport-benchmarks/blob/master/run-aeron.sh

• io.easyLogic.benchmarks.AeronPingBenchmarkJLBHSingleThread（默认）
• IO.EasyLogic.Benchmarks.AeronPingBenchmarkJLBHSeparateThread
• IO.EasyLogic.Benchmarks.AeronPingBenchmarkHDR直方图

Answer 1

您会看到不同的结果，因为基准并不是在测量相同的东西。

AeronPingBenchmarkHdrHistogram测量的只是理想情况，即一条消息被发送，然后立即被消耗。由于发送方和接收方同步运行，因此没有队列效应。创建新消息时，它将获得此特定发送尝试的时间戳。但是，对于整个基准应该运行多长时间没有限制，因此不能定义发送速率。假设其中一个发送需要一个很长的GC暂停（例如1秒），那么只有这个发送结果是坏的，但其余的将不受影响。

JLBH基准是不同的，因为它们添加了时间的概念。例如，在您的结果中，单次运行的持续时间为5秒，例如：

   Run time: 5.0s
   Correcting for co-ordinated:true
   Target throughput:10000/s = 1 message every 100us
   End to End: (50,000)       50/90 99/99.9 99.99 - worst was 14 / 16  20 / 1,660  3,770 - 4,010
   OS Jitter (5,853)          50/90 99/99.9 99.99 - worst was 1.8 / 7.0  30 / 181  3,770 - 3,770

这将基准从发送50K消息更改为在5秒内发送50K消息。在同一示例中，JLBH确定目标速率为10k/秒，并且它将使用该信息计算消息开始时间(starttimens)。在这种情况下，1秒的GC暂停将影响该事件之后的所有消息，因为至少有10K消息将无法按时发送，而且所有其他消息也将因该暂停而延迟。因此，联合联络小组正在努力避免协调疏漏问题。它似乎也有一些逻辑来纠正CO并且它在您的基准测试中是活跃的（例如corretoring for co-ordinated:true)，这也可能会扭曲结果。

最后，AeronPingBenchmarkJlbhSeparateThread基准测试的结果更糟，因为现在您看到了队列效应。发送方发送的速度更快，然后接收方就可以消耗建立起来的队列，所有的事情都以最大容量运行，延迟也就白费了。此外，您的背压处理代码也不正确，即您不能对两个线程使用相同的idleStrategy实例。你需要有两个。

看看Real-Logic/benchmarks项目，它包含Aeron、gRPC和Kafka的发送/接收样式的基准测试。它有自己的基准测试工具LoadTestRig，用于照顾或预热、测量、直方图等，为其他系统添加基准测试是很简单的。