在这篇文章中：
- 在运行JLBH时考虑或不考虑协调遗漏
- 一个示例，以数字说明协同遗漏的效果
- 关于流量控制的讨论
这是我用来描述如果不考虑协调遗漏而进行测量的情况下的示例：
假设您正在等待火车，但由于前面的火车晚了，因此在车站延迟了一个小时。 让我们想象一下，您晚点一个小时上火车，而火车通常需要半个小时才能到达目的地。 如果您不考虑协调遗漏，即使您在出发前在车站等了一个小时，您的旅程也花费了正确的时间，因此您不会认为自己遭受了任何延误！
但这正是运行微型基准测试时要做的。 您为每个“旅程”计时，而不是等待时间。
事实是，对于微型基准测试来说绝对没问题。 但是，当您要测量应用程序的延迟时，这并不理想。
默认情况下，尽管您确实设置了不考虑协调遗漏的计量功能，但JLBH度量端到端时间考虑了协调遗漏。
我写了这个简单的基准，以说明协调遗漏产生的影响有多大。
在此示例中，每隔10k迭代后，我们添加一毫秒的延迟：
package org.latency.spike;
import net.openhft.chronicle.core.Jvm;
import net.openhft.chronicle.core.jlbh.JLBH;
import net.openhft.chronicle.core.jlbh.JLBHOptions;
import net.openhft.chronicle.core.jlbh.JLBHTask;
/**
* A simple JLBH example to show the effects od accounting for co-ordinated omission.
* Toggle the accountForCoordinatedOmission to see results.
*/
public class SimpleSpikeJLBHTask implements JLBHTask {
private int count = 0;
private JLBH lth;
public static void main(String[] args){
JLBHOptions lth = new JLBHOptions()
.warmUpIterations(40_000)
.iterations(1_100_000)
.throughput(100_000)
.runs(3)
.recordOSJitter(true)
.accountForCoordinatedOmmission(true)
.jlbhTask(new SimpleSpikeJLBHTask());
new JLBH(lth).start();
}
@Override
public void run(long startTimeNS) {
if((count++)%10_000==0){
//pause a while
Jvm.busyWaitMicros(1000);
}
lth.sample(System.nanoTime() - startTimeNS);
}
@Override
public void init(JLBH lth) {
this.lth = lth;
}
} 如果您设置了ordinatedOmission coordinatedOmission(false)那么您将获得此配置文件–正如预期的那样，毫秒延迟只能在最高的百分位数（从第99.99个百分位数开始）中看到。 或这样说，它只影响每10k迭代中的一个-并不令人惊讶。
Warm up complete (40000 iterations took 0.046s)
-------------------------------- BENCHMARK RESULTS (RUN 1) -----------
Run time: 11.593s
Correcting for co-ordinated:false
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.11 / 0.13 0.20 / 0.33 999 / 999 - 1,930
OS Jitter (14,986) 50/90 99/99.9 99.99 - worst was 8.4 / 15 68 / 1,080 3,210 - 4,330
----------------------------------------------------------------------
-------------------------------- BENCHMARK RESULTS (RUN 2) -----------
Run time: 11.49s
Correcting for co-ordinated:false
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.11 / 0.13 0.16 / 0.28 999 / 999 - 999
OS Jitter (13,181) 50/90 99/99.9 99.99 - worst was 8.4 / 12 36 / 62 270 - 573
----------------------------------------------------------------------
-------------------------------- BENCHMARK RESULTS (RUN 3) -----------
Run time: 11.494s
Correcting for co-ordinated:false
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.11 / 0.13 0.16 / 0.26 999 / 999 - 1,030
OS Jitter (13,899) 50/90 99/99.9 99.99 - worst was 8.4 / 13 42 / 76 160 - 541
----------------------------------------------------------------------
-------------------------------- SUMMARY (end to end)-----------------
Percentile run1 run2 run3 % Variation
50: 0.11 0.11 0.11 0.00
90: 0.13 0.13 0.13 0.00
99: 0.20 0.16 0.16 3.31
99.9: 0.33 0.28 0.26 3.88
99.99: 999.42 999.42 999.42 0.00
99.999: 999.42 999.42 999.42 0.00
worst: 1933.31 999.42 1032.19 2.14
---------------------------------------------------------------------- 但是，如果设置了coordinatedOmission(true)则会看到此延迟的真实效果。
Warm up complete (40000 iterations took 0.044s)
-------------------------------- BENCHMARK RESULTS (RUN 1) -----------
Run time: 11.0s
Correcting for co-ordinated:true
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.11 / 0.17 385 / 1,930 4,590 / 5,370 - 5,370
OS Jitter (13,605) 50/90 99/99.9 99.99 - worst was 8.4 / 15 68 / 1,080 5,110 - 5,900
----------------------------------------------------------------------
-------------------------------- BENCHMARK RESULTS (RUN 2) -----------
Run time: 11.0s
Correcting for co-ordinated:true
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.12 / 0.18 42 / 901 999 / 999 - 1,030
OS Jitter (13,156) 50/90 99/99.9 99.99 - worst was 8.4 / 13 38 / 68 209 - 467
----------------------------------------------------------------------
-------------------------------- BENCHMARK RESULTS (RUN 3) -----------
Run time: 11.0s
Correcting for co-ordinated:true
Target throughput:100000/s = 1 message every 10us
End to End: (1,100,000) 50/90 99/99.9 99.99/99.999 - worst was 0.12 / 0.18 46 / 901 999 / 999 - 999
OS Jitter (13,890) 50/90 99/99.9 99.99 - worst was 8.4 / 14 44 / 80 250 - 1,870
----------------------------------------------------------------------
-------------------------------- SUMMARY (end to end)-----------------
Percentile run1 run2 run3 % Variation
50: 0.11 0.12 0.12 0.00
90: 0.17 0.18 0.18 0.00
99: 385.02 41.98 46.08 6.11
99.9: 1933.31 901.12 901.12 0.00
99.99: 4587.52 999.42 999.42 0.00
99.999: 5373.95 999.42 999.42 0.00
worst: 5373.95 1032.19 999.42 2.14
----------------------------------------------------------------------实际上，每百次迭代（而不是10,000次迭代）在某种程度上会受到影响。 当您抬高百分位数时，您还可以看到延迟的逐步影响。
这清楚地表明了为什么协调遗漏必须成为基准测试的重要组成部分，尤其是如果您不能在程序中进行流控制时。 如果您不跟上进度，流量控制是一种停止消耗的功能，例如，如果您太忙，则将用户赶出站点。 Fix Engines无法施加流量控制，即您无法跟上市场的步伐，因为您无法跟上潮流！ 进行流控制的程序以消费者为中心，而不进行流控制的程序以生产者为中心。
协调遗漏的考虑与能够为定义的吞吐量设置延迟密切相关，这将在下一个示例中介绍。
翻译自: https://www.javacodegeeks.com/2016/04/jlbh-examples-2-accounting-coordinated-omission.html
扫一扫
550
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
