JLBH示例2 –协调遗漏的会计处理

在这篇文章中：

在运行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();}@Overridepublic void run(long startTimeNS) {if((count++)%10_000==0){//pause a whileJvm.busyWaitMicros(1000);}lth.sample(System.nanoTime() - startTimeNS);}@Overridepublic 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无法施加流量控制，即您无法跟上市场的步伐，因为您无法跟上潮流！进行流控制的程序以消费者为中心，而不进行流控制的程序以生产者为中心。

协调遗漏的考虑与能够为定义的吞吐量设置延迟密切相关，这将在下一个示例中介绍。