了解一个系统的性能一般是參考一些度量值(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 &amp; Utilization Law的更多相关文章

  1. 高性能Linux服务器 第10章 基于Linux服务器的性能分析与优化

    高性能Linux服务器 第10章    基于Linux服务器的性能分析与优化 作为一名Linux系统管理员,最主要的工作是优化系统配置,使应用在系统上以最优的状态运行.但硬件问题.软件问题.网络环境等 ...

  2. SQL Server-聚焦INNER JOIN AND IN性能分析(十四)

    前言 本节我们来讲讲联接综合知识,我们在大多教程或理论书上都在讲用哪好,哪个性能不如哪个的性能,但是真正讲到问题的实质却不是太多,所以才有了本系列每一篇的篇幅不是太多,但是肯定是我用心去查找许多资料而 ...

  3. SQL2005性能分析一些细节功能你是否有用到?

    原文:SQL2005性能分析一些细节功能你是否有用到? 我相信很多朋友对现在越来越大的数据量而感到苦恼,可是总要面对现实啊,包括本人在内的数据库菜鸟们在开发B/S程序时,往往只会关心自己的数据是否正确 ...

  4. 常用排序算法的python实现和性能分析

    常用排序算法的python实现和性能分析 一年一度的换工作高峰又到了,HR大概每天都塞几份简历过来,基本上一天安排两个面试的话,当天就只能加班干活了.趁着面试别人的机会,自己也把一些基础算法和一些面试 ...

  5. 如何优化你的布局层级结构之RelativeLayout和LinearLayout及FrameLayout性能分析

    转载请注明出处:http://blog.csdn.net/hejjunlin/article/details/51159419 如何优化你的布局层级结构之RelativeLayout和LinearLa ...

  6. 【转】一文掌握 Linux 性能分析之 I/O 篇

    [转]一文掌握 Linux 性能分析之 I/O 篇 这是 Linux 性能分析系列的第三篇,前两篇分别讲了 CPU 和 内存,本篇来看 IO. IO 和 存储密切相关,存储可以概括为磁盘,内存,缓存, ...

  7. 【原创】一文掌握 Linux 性能分析之 I/O 篇

    本文首发于我的公众号 Linux云计算网络(id: cloud_dev),专注于干货分享,号内有 10T 书籍和视频资源,后台回复「1024」即可领取,欢迎大家关注,二维码文末可以扫. 一文掌握 Li ...

  8. 『高性能模型』Roofline Model与深度学习模型的性能分析

    转载自知乎:Roofline Model与深度学习模型的性能分析 在真实世界中,任何模型(例如 VGG / MobileNet 等)都必须依赖于具体的计算平台(例如CPU / GPU / ASIC 等 ...

  9. Linux性能分析的前60000毫秒【转】

    Linux性能分析的前60000毫秒 为了解决性能问题,你登入了一台Linux服务器,在最开始的一分钟内需要查看什么? 在Netflix我们有一个庞大的EC2 Linux集群,还有非常多的性能分析工具 ...

随机推荐

  1. 用css实现html中单选框样式改变

     我们都知道,input的单选框是一个小圆框,不能直接更改样式.但是我们在很多网页中看到的单选框样式可不仅限于默认的那个样式(看上去没啥新意,也比较丑).那么,接下来我将介绍下如何实现该功能. 首先, ...

  2. RPM Package Manager

    本文大部分内容来自鸟哥的Linux私房菜,并且由作者根据自己的学习情况做了一些更改,鸟哥原文链接 1. 程序的安装方式 源代码安装:利用厂商释出的Tarball 来进行软件的安装,每次安装程序都需要检 ...

  3. 为什么JavaScript里面0.1+0.2 === 0.3是false

    以下这一篇说明的很详细:彻底理解0.1 + 0.2 === 0.30000000000000004的背后 0.1+0.2 === 0.3 //返回是false, 这是为什么呢?? 我们知道浮点数计算是 ...

  4. ps---图层,移动工具

    1.移动图层从一个文件到另一个文件相当于复制,如果俩文件大小相同,开始移动后,按下shift键,可保持原来位置.若不相同,拖拽后,按shift,则会自动居中.如果目标文档包含选区,会到选区的中央. 2 ...

  5. 「问题思考」python的递归中return返回none

    代码: #求最大公约数 def gcd(x,y): if x < y: swap = x x = y y = swap if x%y == 0: return y else: gcd(y,x%y ...

  6. 有关OEP脱壳

    首先补充: OEP:(Original Entry Point),程序的入口点,软件加壳就是隐藏了OEP(或者用了假的OEP), 只要我们找到程序真正的OEP,就可以立刻脱壳. PUSHAD (压栈) ...

  7. LeetCode 309. Best Time to Buy and Sell Stock with Cooldown (stock problem)

    Say you have an array for which the ith element is the price of a given stock on day i. Design an al ...

  8. .NET中的缓存实现

    软件开发中最常用的模式之一是缓存,这是一个简单但非常有效的概念,想法是重用操作结果,执行繁重的操作时,我们会将结果保存在缓存容器中,下次我们需要该结果时,我们将从缓存容器中取出它,而不是再次执行繁重的 ...

  9. js正则替换十六进制

    var re=/\x62/;//没有0,也没有分号。alert(re.test("blue"));  //output "true" 需要使用< 如需显示 ...

  10. BeautifulSoup4系列一

    前言 以博客园为例,爬取我的博客上首页的发布时间.标题.摘要,本篇先小试牛刀,先了解下它的强大之处,后面讲beautifulsoup4的详细功能. 一.安装 1.打开cmd用pip在线安装beauti ...