排队理论之性能分析 - Little Law & Utilization Law
了解一个系统的性能一般是參考一些度量值(Metric),而怎样计算出这些Metric就是我们要讨论的。Little Law(排队理论:利特儿法则)和Utilization Law是Performance Engineering(System Engineering的一部分)经常使用的法则,它们都是数学理论,因此可作为性能计算的理论根据。具体分析两个法则超出了我个人的知识范围。因此我将只谈一下怎样应用。
在这之前我有写过存储系统性能 - 带宽计算,当中就应用到了Little Law和Utilization Law,大家能够參考一下。
Little Law 是由Philip M.Morse在1954年提出,公式为L = λW,但当时并没有被证明,所以只如果为正确。而一直被人们使用着。Philip希望读者可以提供这样的关系所不适用的情况来推翻它。
John Little在1961年证明了并没有一种情况不适用于Little Law,从而为Little Law的正确性提供了理论证明。
Little Law定义了(以超市为例):在一个稳定的系统中。长时间观察到的平均顾客数量L = 长时间观察到的有效顾客到达速率λ * 平均每一个顾客在系统中花费的时间W,即L = λW。本法则适用于不论什么系统,甚至是一个系统中的子系统,比方一家银行的客户队列。唯一的要求就是系统必须是稳定的。非抢占式的。
为了更好的理解Little Law,请考虑一家仅有一个柜台的小型超市。柜台每次仅仅能服务一位顾客。而且如果全部人都会买东西。这个系统的工作流程能够化简为:入店 -> 浏览 -> 结账 -> 离开。这是一个稳定的系统。如果【顾客进入超市的速率 > 顾客离开超市的速率】。即Arrival rate > Exit rate,那么系统就会開始不稳定。由于等待的客户队列会逐渐变得无限长。
- Little Law告诉我们:超市内的平均客户数量L = 客户到达速率λ * 客户在超时内的逗留时间W,即L = λW
- 如果客户达到速率为10人/小时,平均每一个人在超市内逗留0.5小时,那么该超市在不论什么一个时间点的顾客数量 L= 10 * 0.5 = 5人
- 现如果顾客開始蜂拥,达到速率增长至20人/小时,如果顾客逗留时间不变依旧为0.5小时,那么超市必须可以容纳 L=20*0.5 = 10人,否则都多出的5人须要在超市外等待;如果超市临时无法扩容。即仅仅能容纳5人。为了让多出的5人不须要在超市外等待。必须缩短顾客逗留时间W = 5/20 = 0.25小时。
总结来说,在流量添加的情况下。为了保证系统稳定执行(保持一个可接受的队列长度,从而保证可接受的响应时间),即超市在随意时间点都能保证可以服务5位顾客的能力,依据Little Law法则,有两种方案:
- 第一:扩大超市容量(建造更大的超市)
- 第二:降低顾客逗留时间(提高柜台效率,比方添加柜台数量。培训柜台人员)
====================================================
说了那么多都没提到性能,别急。假设我们把相同的样例应用到磁盘系统。即:
l 确保磁盘稳定执行所同意的最大请求数量 L
l I/O请求达到速率 λ
l 磁盘处理每个I/O所花费的时间 W
因此,保证一块磁盘稳定执行所同意的最大I/O请求数量 L = I/O请求达到速率λ * 磁盘处理每个I/O所花费的时间W,即L = λW;同理,对于一个I/O控制器,到达速率必须 < 服务速率,或者说服务时间必须 < 内部到达时间,否则I/O控制器的处理能力无法满足过量的I/O请求,必定会导致性能下降。
结合Utilization Law(不介绍了。直接应用。它可用于描写叙述I/O控制器的利用率)。公式为 U = λ * Rs
l U = I/O控制器的利用率
l Rs = 服务时间,即控制器处理一个I/O的平均时间,对于磁盘来说,服务时间 Rs = 寻道时间 + 旋转延迟 + 内部传输速率(数据从一个盘面上的单个磁道传输到Buffer的速率)。所以一般是一个定值,由磁盘本身的物理特性决定。
l λ = 到达速率
Little Law + Utilization Law能够推导出例如以下公式(推导过程省略,直接用)
l 平均响应时间 R = Rs / (1-U)
l 平均队列长度 Nq = U^2 /(1-U)
有了如上这些公式。我们来考虑这样一个磁盘系统, λ = 100个/秒,Rs = 8ms。我们能够得到
l 磁盘利用率 U = Rs / Ra = 8/10 = 0.8或80%
l 响应时间R = Rs / (1-U) = 8/(1-0.8) = 40ms
l 平均队列长度Nq = U^2 / (1-U) = 0.8^2 / (1-0.8) = 3.2
l 一个请求在队列中的等待时间 = 【U * Rs】或【响应时间 – 服务时间】 = 40 – 8 = 32ms
若把控制器处理能力加倍,则服务时间和利用率都会减半,Rs = 4ms。U = 40%。
此时,响应时间R能够大大减少;同理。假设处理能力减半,那么服务时间和利用率都会极大添加。这里有一个很重要的概念。就是我们常常提到的,随着利用率添加到某一个点。假设继续上升,那么响应时间会呈指数形式增长,也就是说R和U并非线性的关系,我们分析一下【响应时间R = Rs / (1-U)】来看看是为什么:
平均响应时间 R = Rs / (1-U),Rs是定值。可见。当U = 1时,也就是控制器饱和时。【响应时间R】趋近于无穷大,这是一个极限的概念,
。当U趋向于1时,又Rs是常量,所以R趋向于无穷大。
因此。处于100%利用率的控制器就是瓶颈所在,它会迫使I/O序列化(I/O serialization),即每一个I/O都必须在队列中等待它前面的I/O被处理完成之后才干得到服务。一旦队列无限加大(一般buffer会有控制机制阻止队列的无限增长,比方Fiber Channel BB Credit,TCP Window,Ethernet PAUSE等等),响应时间会急剧上升。
通常我们都觉得当利用率达到70%以后。未来的继续增长会使得性能以指数形式下降。而不是线性的。
为什么是非线性的。大家能够尝试画一下 R= Rs/ (1-U) 的函数图像,在U逐渐趋向于1时,R趋向于无穷大,垂直渐近线是 x = 1。只是我不明确70%是怎样计算出来的,可能是求U在 [0,1)范围内的导数通过比較斜率变化率来推断的?其实,当U取0.9,0.99,0.999,....,0.9999999时。你会发现R = 10Rs, 100Rs, 1000Rs,....,10000000Rs,R以指数形式增长。
而U取0.1,0.11,0.111时,R的添加就缓慢非常多。
随着U的取值添加,R的上升趋势也会以非线性的方式呈上升趋势。70%可能是通过数学方式计算得到。也可能仅仅是一个比較得来的经验值,擅长数学的朋友能够补充说明一下。

排队理论之性能分析 - Little Law & Utilization Law的更多相关文章
- 高性能Linux服务器 第10章 基于Linux服务器的性能分析与优化
高性能Linux服务器 第10章 基于Linux服务器的性能分析与优化 作为一名Linux系统管理员,最主要的工作是优化系统配置,使应用在系统上以最优的状态运行.但硬件问题.软件问题.网络环境等 ...
- SQL Server-聚焦INNER JOIN AND IN性能分析(十四)
前言 本节我们来讲讲联接综合知识,我们在大多教程或理论书上都在讲用哪好,哪个性能不如哪个的性能,但是真正讲到问题的实质却不是太多,所以才有了本系列每一篇的篇幅不是太多,但是肯定是我用心去查找许多资料而 ...
- SQL2005性能分析一些细节功能你是否有用到?
原文:SQL2005性能分析一些细节功能你是否有用到? 我相信很多朋友对现在越来越大的数据量而感到苦恼,可是总要面对现实啊,包括本人在内的数据库菜鸟们在开发B/S程序时,往往只会关心自己的数据是否正确 ...
- 常用排序算法的python实现和性能分析
常用排序算法的python实现和性能分析 一年一度的换工作高峰又到了,HR大概每天都塞几份简历过来,基本上一天安排两个面试的话,当天就只能加班干活了.趁着面试别人的机会,自己也把一些基础算法和一些面试 ...
- 如何优化你的布局层级结构之RelativeLayout和LinearLayout及FrameLayout性能分析
转载请注明出处:http://blog.csdn.net/hejjunlin/article/details/51159419 如何优化你的布局层级结构之RelativeLayout和LinearLa ...
- 【转】一文掌握 Linux 性能分析之 I/O 篇
[转]一文掌握 Linux 性能分析之 I/O 篇 这是 Linux 性能分析系列的第三篇,前两篇分别讲了 CPU 和 内存,本篇来看 IO. IO 和 存储密切相关,存储可以概括为磁盘,内存,缓存, ...
- 【原创】一文掌握 Linux 性能分析之 I/O 篇
本文首发于我的公众号 Linux云计算网络(id: cloud_dev),专注于干货分享,号内有 10T 书籍和视频资源,后台回复「1024」即可领取,欢迎大家关注,二维码文末可以扫. 一文掌握 Li ...
- 『高性能模型』Roofline Model与深度学习模型的性能分析
转载自知乎:Roofline Model与深度学习模型的性能分析 在真实世界中,任何模型(例如 VGG / MobileNet 等)都必须依赖于具体的计算平台(例如CPU / GPU / ASIC 等 ...
- Linux性能分析的前60000毫秒【转】
Linux性能分析的前60000毫秒 为了解决性能问题,你登入了一台Linux服务器,在最开始的一分钟内需要查看什么? 在Netflix我们有一个庞大的EC2 Linux集群,还有非常多的性能分析工具 ...
随机推荐
- InnoDB INFORMATION_SCHEMA Lock Tables
InnoDB INFORMATION_SCHEMA Lock Tables 三张InnoDB INFORMATION_SCHEMA表使您能够监视事务并诊断潜在的锁定问题: INNODB_TRX:提供有 ...
- echart使用自定义单个柱状颜色实现
项目实践中遇到一个根据需要,当X轴等于某个值是,柱状变成特殊颜色的需求,大致有两个方案实现: 1.在前台遍历数据对象,判断设置: 2.在后台拼装数据是,按照格式要求拼装好: 手拉手,用Vue开发动态刷 ...
- 项目:开发->测试->上线:流程规范
1) 项目分析 2) 项目经理分工协作 程序就具体流程: 1: 按项目名称: 建git, 数据库, 线上测试虚拟机 2: 按项目经理分配的大的模块. 自行划分工作阶段 a: 划分为小的模块 b: 预估 ...
- (一)Robot Framework安装
准备工作: Python 2.7 (目前不能良好支持python3) pip 和 setuptools (Python 的套件管理程式,最新版的Python 2.7.16已包含) Robot Fram ...
- 转载 js弹出框、对话框、提示框、弹窗总结
转载:https://blog.csdn.net/huileiforever/article/details/9464659 一.JS的三种最常见的对话框 //================== ...
- zzuli 1905 小火山的跳子游戏
Description 小火山和火山火山在一块玩跳子游戏.规则如下: 1:跳子的起始位置为0,棋盘大小从1到N 2:每次跳子跳k步. 例如当前位置为i, 那么下一步为i + k 3:跳 ...
- 为应用指定多个struts配置文件
在大部分应用里,随着应用规模的增加,系统中Action的数量也会大量增加,导致struts.xml配置文件变得非常臃肿.为了避免struts.xml文件过于庞大.臃肿,提高struts.xml文件的可 ...
- POJ 3036 Honeycomb Walk
http://poj.org/problem?id=3036 在每一个格子可以转移到与这个各自相邻的六个格子 那么设置转移变量 只需要六个 int d[6][2] = {-1, 0, -1, 1, 0 ...
- 【linux】ls与ll区别
ll是一个事先被定义好的别名(alias).别名就是赋予一条命令或者一列命令的名称.可以将别名作为缩写的同义词.在我的Ubuntu系统上,~/.bashrc文件中有这么一条语句alias ll='ls ...
- JS中的call()和apply()方法区别
如 果没接触过动态语言,以编译型语言的思维方式去理解javaScript将会有种神奇而怪异的感觉,因为意识上往往不可能的事偏偏就发生了,甚至觉得不可 理喻.如果在学JavaScript这自由而变幻无穷 ...
