如何解决运输基准的不同结果
我在介绍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
我很有可能在某个地方搞砸了,但就目前而言,所有三个基准测试看起来或多或少与我相似,但是工具集不同。
非常感谢!
P.S。
如果有人想自己尝试,则只需运行此脚本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
解决方法
您看到的结果不同,因为基准测试无法衡量同一事物。
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 / sec,它将使用此信息来计算消息开始时间(startTimeNS
)。在这种情况下,GC暂停1秒将影响此事件之后的所有消息,因为不会按时发送至少10K消息,而且此暂停还会延迟所有其他消息。因此,JLBH正在尝试避免使用Coordinated Omission Problem。似乎还有一些逻辑可以校正CO,并且在您的基准测试中很活跃(例如Correcting for co-ordinated:true
),这也可能会使结果产生偏差。
最后,AeronPingBenchmarkJlbhSeparateThread基准测试的结果甚至更糟,因为现在您看到了排队效应。发送方发送速度更快,然后接收方可以消耗建立的队列,所有内容均以最大容量运行,而延迟则不堪重负。同样,您的背压处理代码也不正确,即您不能为两个线程使用相同的IdleStrategy
实例。您需要有两个。
看看real-logic/benchmarks项目,其中包含Aeron,gRPC和Kafka的发送/接收样式基准。它具有自己的基准测试工具LoadTestRig,用于处理或进行预热,测量,直方图等。为其他系统添加基准测试很简单。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。