运输基准测试的结果不同

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。

但是这些结果有点让我困惑...

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

• 单线程 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 我很可能在某个地方搞砸了，但现在，所有三个基准测试在我看来看起来更或多或少相似，但使用不同的工具集。

非常感谢！

附言。

如果有人想自己尝试，请运行此脚本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

- QIvan

Answer 1

您看到不同的结果是因为基准测试没有测量相同的内容。 AeronPingBenchmarkHdrHistogram 只测量理想情况，即发送一条消息并立即消费。没有排队效应，发送方和接收方在锁步运行。创建新消息时，它会获得此特定发送尝试的时间戳。但整个基准测试应该运行多长时间没有限制，因此不能定义“发送速率”。想象一下，如果其中一个发送操作暂停很长时间（例如 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试图避免协调省略问题。它似乎还有一些逻辑来纠正CO，并且在您的基准测试中处于活动状态（例如，Correcting for co-ordinated:true），这可能会扭曲结果。

最后，AeronPingBenchmarkJlbhSeparateThread基准测试结果更糟糕，因为现在你看到了队列效应。发送方发送速度比接收方消费速度快，队列会不断增加，所有内容都运行在最大容量下，延迟降至谷底。此外，你的反压处理代码不正确，即你不能为两个线程使用相同的IdleStrategy实例，你需要有两个实例。

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

- Dmitry Vyazelenko