运输基准的不同结果

Question

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

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

• 我的代码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/io/easylogic/benchmarks/AeronPingBenchmarkJlbhSingleThread.java
• 1 个线程发布者/1 个线程接收者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
• 1 个线程发布者/1 个线程接收者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

要选择要运行的版本，请在此处更改参数mainClassName： https://github.com/easy-logic/transport-benchmarks/blob/master/aeron-ping/build.gradle#L6

有 3 个选项：

• io.easylogic.benchmarks.AeronPingBenchmarkJlbhSingleThread（默认）
• io.easylogic.benchmarks.AeronPingBenchmarkJlbhSeparateThread
• io.easylogic.benchmarks.AeronPingBenchmarkHdrHistogram

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 消息不会按时发送，而且所有进一步的消息都会被此暂停延迟。因此，JLBH 试图避免Coordinated Omission Problem。它似乎也有一些逻辑可以纠正 CO，并且它在您的基准测试中很活跃（例如 Correcting for co-ordinated:true），这也可能会扭曲结果。

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

查看 real-logic/benchmarks 项目，其中包含 Aeron、gRPC 和 Kafka 的发送/接收样式基准。它有自己的基准测试工具LoadTestRig，可以处理或预热、测量、直方图等。为其他系统添加基准测试也很简单。