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无法施加流量控制,即您无法跟上市场的步伐,因为您无法跟上潮流! 进行流控制的程序以消费者为中心,而不进行流控制的程序以生产者为中心。
协调遗漏的考虑与能够为定义的吞吐量设置延迟密切相关,这将在下一个示例中介绍。
翻译自: https://www.javacodegeeks.com/2016/04/jlbh-examples-2-accounting-coordinated-omission.html
JLBH示例2 –协调遗漏的会计处理相关推荐
- JLBH示例4 – QuickFix vs ChronicleFix基准化
在这篇文章中: 使用JLBH测试QuickFIX 观察QuickFix延迟如何通过百分位数降低 比较QuickFIX和Chronicle FIX 如JLBH简介中所述,创建JLBH的主要原因是为了测量 ...
- JLBH示例3 –吞吐量对延迟的影响
在这篇文章中: 关于吞吐量对延迟的影响的讨论 如何使用JLBH测量TCP回送 添加探针以测试TCP往返的两半 观察增加吞吐量对延迟的影响 了解必须降低吞吐量才能在高百分位数时获得良好的延迟. 在帖子中 ...
- cov/cor中有遗漏值_协调遗漏的效果–使用简单的NIO客户端/服务器测量回送延迟...
cov/cor中有遗漏值 在这篇文章中,我演示了许多想法和技术: 如何编写一个简单的非阻塞NIO客户端/服务器 协同遗漏的影响 如何测量百分位数的延迟(相对于简单平均) 如何在计算机上计时延迟回送 我 ...
- 七层网络性能基准测试中的协调遗漏问题--Coordinated Omission
前言 在讲述这个问题之前首先我们先要搞清楚七层网络测试协议的几个关键性性能测试指标和通用的关系模型.其次搞清楚四层协议,七层协议中性能测试给出的时延讲述的是个什么东西.最后讲述为什么大部分的性能测试工 ...
- JLBH示例1 –为什么应在上下文中对代码进行基准测试
在这篇文章中: 使用JMH和JLBH进行日期序列化的并排示例 在微基准中测量日期序列化 测量日期序列化作为适当应用程序的一部分 如何为您的JLBH基准添加探针 了解在上下文中衡量代码的重要性 在上一篇 ...
- JLBH – Java延迟基准线束介绍
在这篇文章中: 什么是JLBH 我们为什么写JLBH JMH和JLBH之间的区别 快速入门指南 什么是JLBH? JLBH是可用于测量Java程序中的延迟的工具. 它具有以下功能: 旨在运行比微型基准 ...
- 协同遗漏的效果–使用简单的NIO客户端/服务器测量回送延迟
在这篇文章中,我演示了许多想法和技术: 如何编写一个简单的非阻塞NIO客户端/服务器 协调遗漏的影响 如何测量百分位数的延迟(相对于简单平均) 如何在计算机上计时延迟回送 我最近正在为客户端服务器应用 ...
- mac 大写锁定延迟_延迟分析中的案例研究:锁定与同步
mac 大写锁定延迟 特别是在这篇文章中,我们将讨论: java.concurrent.Lock创建的垃圾 比较锁与同步 如何以编程方式测量延迟 争用对锁和同步的影响 遗漏对延迟测试的影响 回到我最喜 ...
- 延迟分析中的案例研究:锁定与同步
特别是在这篇文章中,我们将讨论: java.concurrent.Lock创建的垃圾 比较锁与同步 如何以编程方式测量延迟 争用对锁和同步的影响 协调遗漏对延迟测试的影响 回到我最喜欢的主题之一,垃圾 ...
最新文章
- 参观Speedy Cloud 有感
- 分布式任务队列 Celery — 深入 Task
- 亿万级图数据库 Nebula Graph 的数据模型和系统架构设计
- SQL 注入详解扫盲
- 开发人员必读的11本最具影响力书籍
- console 程序随系统启动及隐藏当前程序窗口
- 客户端与服务器之间的文件传输,客户端与服务器的文件传输
- 看风水用什么罗盘最好_兰花用什么土最好
- 程序中,序列化与反序列化
- JavaSE基础———ArrayList、Vector和LinkedList 泛型 可变参
- 如何用resource hacker快速的去除WinRAR的广告
- Linux FTP搭建及访问
- 大数据时代,数据分析师的职业发展规划
- 安卓监听是否有闹钟设置
- 如何提高自己的分析能力
- 初学者该掌握的计算机知识,初学者该如何学习电脑知识
- 商汤科技面试——AI算法岗
- 用python画皮卡丘画法-用python画一只可爱的皮卡丘
- 留存分析_游戏数据分析
- Traffic shaping 一个事半功倍的程序化”噪音“解决方案
热门文章
- Hibernate之必须导入jar包
- 使用ueditor实现多图片上传案例
- python注释的用法(单and多行)
- 2020蓝桥杯省赛---java---B---5( REPEAT 程序)
- html session 登录页面跳转页面跳转页面,session失效后跳转到登陆页面
- html画等边三角形,前台面试:使用CSS画一个等边三角形
- 如何兼容html在不同分辨力的问题,现代教育技术练习题
- cursor 过滤 android,Android cursor query方法详解
- java泛型程序设计——注意擦除后的冲突
- java无效的源发行版_无效的Java