在這篇文章中：

• 在運行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無法施加流量控制，即您無法跟上市場的步伐，因為您無法跟上潮流！ 進行流控制的程序以消費者為中心，而不進行流控制的程序以生產者為中心。

協調遺漏的考慮與能夠為定義的吞吐量設置延遲密切相關，這將在下一個示例中介紹。

翻譯自: https://www.javacodegeeks.com/2016/04/jlbh-examples-2-accounting-coordinated-omission.html

總結

以上是生活随笔為你收集整理的JLBH示例2 –协调遗漏的会计处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。