文化馆网站建设,怎么自己制作网址,合肥网站建设索q479185700,你有网站 我做房东 只收佣金的网在这篇文章中#xff1a; 在运行JLBH时考虑或不考虑协调遗漏 一个示例#xff0c;以数字说明协同遗漏的效果 关于流量控制的讨论 这是我用来描述如果不考虑协调遗漏而进行测量的情况下的示例#xff1a; 假设您正在等待火车#xff0c;但由于前面的火车晚了#xff0… 在这篇文章中 在运行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_0000){//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无法施加流量控制即您无法跟上市场的步伐因为您无法跟上潮流 进行流控制的程序以消费者为中心而不进行流控制的程序以生产者为中心。 协调遗漏的考虑与能够为定义的吞吐量设置延迟密切相关这将在下一个示例中介绍。 翻译自: https://www.javacodegeeks.com/2016/04/jlbh-examples-2-accounting-coordinated-omission.html
