性能领域包括如下的工作,我们按照理想的执行顺序将它们排列如下:
设置性能目标和建立性能模型
基于软件或者硬件原型进行性能特征归纳
对开发代码进行性能分析(软件整合之前)
执行软件非回滚性测试(软件发布前活发布后)
针对软件发布版本的基准测试
目标环境中的概念验证(Proof-of-concept)测试
生产环境部署的配置优化
监控生产环境运行的软件
特定问题的性能分析
问题分析所有部分:
背景:介绍术语、基本模型、关键性能概念、以及审视问题的视角
方法:讨论性能分析方法,即观察法和实验法;建模;容量规划
指标:介绍性能统计、监控和数据可视化
分析方法:
| 方法 | 类型 |
| 街灯讹方法 | 观测分析 |
| 随机变动讹方法 | 实验分析 |
| 责怪他人讹方法 | 假设分析 |
| AdHoc核对清单法 | 观测与实验分析 |
| 问题陈述法 | 信息收集 |
| 科学法 | 观测分析 |
| 诊断循环 | 生命周期分析 |
| 工具法 | 观测分析 |
| USE 方法 | 观测分析 |
| 工作负载特征归纳 | 观测分析,容量规划 |
| 向下挖掘分析 | 观测分析 |
| 延时分析 | 观测分析 |
| R方法 | 观测分析 |
| 事件跟踪 | 观测分析 |
| 基础线统计 | 观测分析 |
| 性能监控 | 观测分析,容量规划 |
| 排队论 | 统计分析,容量规划 |
| 静态性能调整 | 观测分析,容量规划 |
| 缓存调优 | 观测分析,调优 |
| 微基准测试 | 实验分析 |
| 容量规划 | 容量规划,调优 |
上述方法的由来解释:
街灯讹方法:一天晚上,一个警察看到一个醉汉在路灯下的地面上找东西,问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到,就问他:“你确定你钥匙是在这儿丢的,就在路灯下?”醉汉说:“不,但是这儿的光是最亮的”
随机变动讹方法:这是一个实验性质的讹方法。用户随机猜测问题可能存在的位置,然后做改动,直到问题消失。为了判断性能是否已经提升,或者作为每次变动结果的判断,用户会选择一项指标进行研究,诸如应用程序运行时间、延时、操作率(每秒操作次数),或者吞吐量(每秒的字节数)。
责怪他人讹方法:也许是网络问题。你能和网络团队确认一下是不是发生了丢包或其他事情么?
AdHoc核对清单法:当需要检查和调试系统时,技术支持人员通常会花一点时间一步步地过一遍核对清单。一个典型的场景,在产品环境部署新的服务器或应用时,技术支持人员会花半天的时间来检查-遍系统在真实压力下的常见问题。该类核对清单是 Ad Hoc 的,基于对该系统类型的经验和之前所遇到的问题。
问题陈述法:
明确问题如何陈述是支持人员开始反映问题时的例行工作。通过询问客户以下问题来完成:
1.是什么让你认为存在性能问题?
2.系统之前运行得好吗?
3.最近有什么改动?软件?硬件?负载?
4.问题能用延时或者运行时间来表述吗?
5.问题影响其他的人和应用程序吗(或者仅仅影响的是你)?
6.环境是怎么样的?用了哪此软件和硬件?是什么版本?是怎样的配置?
询问这些问题并得到相应的回答通常会立即指向一个根源和解决方案。因此问题陈述法作为独立的方法收录在此处,而且当你应对一个新的问题时,首先应该使用的就是这个方法
科学法:
科学法研究未知的问题是通过假设和试验。总结下来有以下步骤
1.问题
2.假设
3.预测
4.试验
5.分析
诊断循环:
诊断周期与科学方法相似:
假设一仪器检验一数据一假设
工具法:
工具为导向的方法如下:
1.列出可用到的性能工具(可选的,安装的或者可购买的)
2.对于每一个工具,列出它提供的有用的指标。
3.对于每一个指标,该指标可能的规则
USE 方法:
USE 方法(utilization、saturation、errors)应用于性能研究,用来识别系统瓶颈[Gregg 13]。言以蔽之,就是:
对于所有的资源,查看它的使用率、饱和度和错误。详细见下一篇
工作负载特征归纳:是辨别这样一类问题简单而又高效的方法一一由施加的负载导致的问题。这个方法关注于系统的输人,而不是所产生的性能。你的系统可能没有任何架构或配置上的问题,但是系统的负载超出了它所能承受的合理范围
工作负载可以通过回答下列的问题来进行特征归纳
1.负载是谁产生的?进程D、用户ID远端的I 地址?
2.负载为什么会被调用?代码路径、堆栈跟踪?
3.负载的特征是什么?IOPS、吞吐量方向型(读取/写人)?含变动(标准方差)如果有的话。
4.负载是怎样随着时间变化的?有日常模式吗?
向下挖掘分析:该方法开始于在更专业层检查问题,然后依据之前的发现缩小关注的范围,忽视那些无关的部分,更深入发掘那些相关的部分。整个过程会探究到软件栈较深的级别,如果需要,甚至还可以到硬件层,以求找到问题的根源
延时分析:检查完成一项操作所用的时间,然后把时间再分成小的时间段,接着对有着最大延时的时间段做再次的划分,最后定位并量化问题的根本原因。与深度分析相同,延时分析也会深人到软件栈的各层来找到延时问题的原因。
R方法:该方法是针对Oracle数据库开发的性能分析方法意在找到延时的根源基于Oracle的traceevents[Millsap 03]。它被描述成“基于时间的响应性能提升方法,可以得到对业务的最大经济收,着重于识别和量化查询过程中所消耗的时间。虽然它是用于数据库研究领域,但它的方法思想可以用于所有的系统,作为一种可能的研究手段,值得在此提及。
事件跟踪:系统的操作就是处理离散的事件,包括 CPU 指令、磁盘 O,以及磁命令、网络包、系统调用、函数库调用、应用程序事件、数据库查询,等等。性能分析通常会研究这些事件的汇总数据,诸如每秒的操作数、每秒的字节数,或者是延时的均值。有时一些重要的细节信息不会出现在这些汇总之中,因此最好的研究事件的方法是逐个检查。
基础线统计:把当前的性能指标与之前的数值做比较,对分析问题常常有启发作用。负载和资源使用的变化是可见的,可以把问题回溯到它们刚发生的时候。某些观测工具(基于内核计数器)能显示启动以来的信息统计,可以用来与当前的活动做比较。虽然这比较粗糙,但总好过没有。另外的方法就是做基础线统计。
静态性能调整:静态性能调整处理的是架构配置的问题。其他的方法着重的是负载施加后的性能:动态性能[Elling00]。静态性能分析是在系统空闲没有施加负载的时候执行的。
缓存调优:从应用程序到磁盘,应用程序和操作系统会部署多层的缓存来提高IO的性能
微基准测试:该测量的是施加了简单的人造工作负载的性能。微基准测试可以用于支持科学方法,将假设和预测放到测试中验证,或者作为容量规划的一部分来执行。
来自“性能之巅-Brendan Gregg著”
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/26342786/viewspace-2969878/ ,如需转载,请注明出处,否则将追究法律责任。