性能之巅:洞悉系统、企业与云计算——方法

• 术语
• 模型
• • 受测系统
  • 排队系统
• 概念
• • 延时
  • 时间量级
  • 权衡三角
  • 调整的影响
  • 合适的层级
  • 性能建议的时间点
  • 负载 VS 架构
  • 扩展性
  • 已知的未知
  • 指标
  • 使用率
  • 饱和度
  • 剖析
  • 缓存
• 视角
• • 资源分析
  • 工作负载分析
• 方法
• • 街灯讹方法
  • 随机变动讹方法
  • 责怪他人讹方法
  • Ad Hoc核对清单法
  • 问题陈述法
  • 科学法
  • 诊断循环
  • 工具法
  • USE方法
  • • 过程
    • 指标描述
    • 资源列表
    • 原理框图
    • 指标
    • 软件资源
    • 使用建议
  • 工作负载特征归纳
  • 向下挖掘分析
  • 延时分析
  • 事件跟踪
  • 基础线统计
  • 静态性能调整
  • 缓存调优
  • 微基准测试
• 建模
• • 企业 VS 云
  • 可视化识别
  • Amdahl扩展定律
  • 通用扩展定律
  • 排队理论
• 容量规划
• • 资源极限
  • 因素分析
  • 扩展方案
• 统计
• • 量化性能
  • 平均值
  • 标准方差、百分位数、中位数

面对一个性能不佳且复杂的系统环境时，首先需要知道的挑战就是从什么地方开始分析、收集什么样的数据，以及如何分析这些数据。

方法对于复杂系统的性能分析是有帮助的，告诉我们从哪里开始工作，用什么步骤来定位和分析性能问题。对于新手来说，方法告诉我们从什么地方开始，并列举了如何继续下去的步骤。对于部分用户或专家，方法作为检查清单来使用，确保没有遗漏什么细节。对发现进行量化和确认的方法都包括在内，从而分辨出最紧要的性能问题。

术语

• IOPS：每秒发生的输入/输出操作的次数，是数据传输的一个度量方法。对于磁盘的读写，IOPS指的是每秒读和写的次数。
• 吞吐量：评价工作执行的速率，尤其是在数据传输方面，这个术语用于描述数据传输速度（字节/秒或比特/秒）。在某些情况下（如数据库），吞吐量指的是操作的速度（每秒操作数或每秒业务数）
• 响应时间：一次操作完成时间。包括用于等待和服务的世界，也包括用来返回结果的世界。
• 延时：延时是描述操作里用来等待服务的世界。在某些情况下，它可以指的是整个操作时间，等同于响应时间。
• 使用率：对于服务请求的资源，使用率描述在所给定的时间区间内资源的繁忙程度。对于存储资源来说，使用率指的就是所消耗的存储容量
• 饱和度：指的是某一资源无法满足服务的排队工作量
• 瓶颈：在系统性能里，瓶颈指的是限制系统性能的那个资源。分辨和移除瓶颈是系统性能的一项重要工作
• 工作负载：系统的输入或者是对系统所施加的负载叫做工作负载。对于数据库来说，工作负载就是客户端发出的数据库请求和命令
• 缓存：用于复制或者缓冲一定量数据的高速存储区域，目的是为了避免对较慢的存储层级的直接访问，从而提高性能。处于经济考虑，缓存区的容量要比更慢一级的存储容量要小。

模型

下面的简易模型阐述了系统性能的一些基本原则。

受测系统

受测系统（SUT，system under test）的性能如下图所示：

概念

对于某些环境，延时是唯一关注的性能焦点。而对于其他环境，它会是除了吞吐量以外，数一数二的分析要点。

延时

对于某些环境，延时是唯一关注的性能焦点。而对于其他环境，它会是除了吞吐量以外，数一数二的分析要点。

在应用程序层级寻求性能的巨大提示，还有一个理由。如今许多环境都致力于特性和功能的快速部署，因此应用程序的开发和测试倾向于关注正确性，留给性能测量和优化的时间很少甚至没有。之后当性能成为问题时，才会去做这些与性能相关的事情。

虽然发送在应用程序层级的调整效果最显著。但这个层级不一定是观测效果最显著的层级。数据库查询缓慢要从其所花费的CPU时间、文件系统和所执行的磁盘I/O方面来考察最好。使用操作系统工具，这些都是可以观测到的。

在许多环境里（尤其是云服务器），应用程序承受的是快速部署，每周或每天都有软件变更发送在生产环境。大的性能增长点和软件变化一样频繁地被发现。在这些系统里，操作系统的调整以及从操作系统层面观测问题这两点都容易被忽视。谨记一点操作系统的性能分析能辨别出来的不仅仅是操作系统层级的问题，还有应用程序层级的问题，在某些情况下，甚至要比应用程序视角还简单。

合适的层级

不同的公司和环境对于性能有着不同的需求。我们可能加入过这样的公司，其分析标准要比之前所见的深的多，或者压根都没听过。或者是这样的公司，我们觉得很基本的分析被认为很高端甚至从未使用。

这不表示某些公司做的是对的，有些做的是错的。这取决于性能技术投入的投资回报率（ROI）。拥有大型数据中心或者云环境的公司可能需要一个性能工程师团队来分析所有事情，包括内核内部和CPU性能计数器，并且经常使用动态跟踪技术。这些中心或公司也会正式建立性能模型对将来的增长做预测。小的创业公司可能只能做到浅层次的检查，用第三方的监控方案来检测性能和提供报警。

性能建议的时间点

环境的性能特性会随着时间改变，更多的用户、新的硬件、升级的软件或固件都是变化的因素。一个环境，受限于速度1Gb/s网络基础设施，当升级到10Gb/s时，很可能磁盘或CPU性能变得紧张、

性能推荐，尤其是可调整的参数值，仅仅在一段特定时间内有效。可能过了一周，用户量激增，或者经过一次软件升级或硬件升级就无效了。

负载 VS 架构

应用程序性能差可能是因为软件配置和硬件的问题，也就是它的架构问题。另外，应用程序性能差还可能是由于有太多负载，而导致了排队和长延时。如下图所示

如果对于结构的分析只是显示工作任务的排队，处理任务没有任何问题，那么问题就可能出在施加的负载太多。在云环境中，这是需要引入更多的节点来处理任务的征兆。

例如，架构的问题可能是一个单线程的应用程序在单个CPU上忙碌，从而致使请求排队的情况，但是其他的CPU却是可用且空闲的。在这里性能就被应用程序的单一线程架构限制住了。

在一定阶段，可以观察到扩展性是线性变化的。随着到达某一点，用虚线标记，此处对于资源的争夺开始影响性能。这一点可以认为是拐点，作为两条曲线的分界。过了这一点后，吞吐量曲线随着资源争夺加剧偏离了线性扩展，内聚性导致完成的工作变少而且吞吐量也减少了。

这个情况可能发生在组件达到100%使用率的时候——饱和点。也可能发生在组件接近100%使用率的时候，这时排队频繁且比较明细。

已知的未知

已知的已知、已知的未知、未知的未知在性能领域是很重要的概念。下面是详细的解释：

• 已知的已知：有些东西我们知道。知道应该检查性能指标，也知道它的当前值。例如，我们应该知道检查CPU使用率，而且也知道当前均值是10%。
• 已知的未知：有些动我们知道我们不知道。知道可以检查一个指标或者判断一个子系统是否存在，但是还没去做。例如，我们知道可以用profiling检查是什么致使CPU忙碌，但是还没去做这件事。
• 未知的未知：有些东西我们不知道我们不知道。例如，我们可能不知道设备中断可以消耗大量CPU资源，因此我们对此并不做检查。

性能领域是“知道的越多，不知道的也就越多”。

指标

性能指标是由系统、应用程序、或者其他工具产生的度量感兴趣活动的统计数据。性能指标用于性能分析和监控，由命令行提供数据或者由可视化工具提供图表。

常见的系统性能指标如下：

• IOPS：每秒的I/O操作数
• 吞吐量：每秒数据量或操作量
• 使用率
• 延时

吞吐量的使用取决于上下文环境。数据库吞吐量通常用来度量每秒查询或请求的数目（操作量）。网络吞吐量度量的是每秒比特或字节数目（数据量）。

IOPS度量的是吞吐量，但只针对I/O操作（读取和写入）。再次重申，上下文很关键，上下文不同，定义可能会有不同。

• 开销：性能指标不是免费的，在某些时候，会消耗一些CPU周期来收集和保持指标信息。这就是开销，对目标的性能会有负面影响。这种影响被称为观察者效应（observer effect）。
• 问题：我们总是倾向于假定软件商的提供的指标是经过仔细挑选，没有bug，并且有很好的可见性。但事实上，指标可能会混淆的、复杂的、不可靠的、不精确的，设置是错的。有时在某一软件版本上对的指标，由于没有得到及时更新，而无法反映新的代码和代码路径。

使用率

使用率经常用于操作系统描述设备的使用情况，诸如CPU和磁盘设备。使用率是基于时间的，或者是基于容量。

• 基于时间：基于时间的使用率是使用排队理论做正式定义的。
  服务器或资源繁忙时间的均值：
  相应的比例公式是：
  U=B/T
  此处U是使用率，B是T时间内系统的繁忙时间，T是观测周期。

• 基于容量：系统或组件（如硬盘）都能提供一定数量的吞吐。不论性能处于何种级别，系统或组件都工作在其容量的某一比例上。这个比例就称为使用率。
  这是用容量而不是时间来定义使用率的。这意味着100%使用率的磁盘不能接受更多的工作。若用时间定义，100%的使用率只是值时间上100%忙碌。
  100%忙碌不意味着100%的容量使用。

饱和度

随着工作量增加而对资源的请求超过资源所能处理的程度叫饱和度。饱和度发生在100%使用率时（基于容量），这时多出的工作无法处理，开始排队。下图描绘了这种情况：

了解缓存性能的另一个指标是缓存的失效率，指的是每秒钟缓存失效的次数。这与每次缓存失效对性能的影响是成比例（线性）关系的。

缓存的热、冷和温：

• 冷：冷缓存是空的，或者填充的是无用的数据。冷缓存的命中率为0
• 热：热缓存填充的都是常用的数据，并有着很高的命中率，例如，超过99%。
• 温：温缓存指的是填充了有用的数据，但是命中率还没达到预想的高度。
• 热度：缓存的热度指的是缓存的热度或冷度。提高缓存热度的目的就是提高缓存的命中率。

当缓存初始化后，开始是冷的，过一段时间后逐渐变暖。如果缓存较大或者下一级的存储较慢（或者两者皆有），会需要一段较长的时间来填充缓存使其变暖。

视角

性能分析有两个常用的视角，每个视角的受众、指标以及方法都不一样。这俩个视角是工作负载分析和资源分析，可以分别对应理解为对系统软件栈自上而下和自底向上的分析，如下图所示：

工作负载分析的对象如下：

• 请求：所施加的工作负载
• 延时：应用程序的响应时间
• 完成度：查找错误

研究工作负载请求一般会涉及检查并归纳负载点，即归纳工作负载属性的过程。对于数据库，这些属性包括客户端机器、数据库名、数据表，以及查询字符串。这些信息可能会有助于识别不必要的工作或者是不均衡的工作。即便是工作执行的很好的情况（低延时），通过检查这些属性，也可能会找到减少或消除所施加的工作负载的方法。

延时（响应时间）是提现应用程序性能最为重要的指标。对于MySQL数据库来说，是查询延时，对于Nginx来说，是HTTP请求延时，诸如此类。在这些上下文里，术语“延时”所表达的和响应时间是一个意思。

方法

街灯讹方法

这个方法实际并不是一个深思熟虑的方法。用户选择熟悉的观测工具来分析性能，这些工具可能是从互联上找到的，或者是用户随意选择的，仅仅想看看会有什么结果出现。这样的方法可能命中问题，也可能忽视很多问题。

性能调整可以用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各种不同的值，看看是否有帮组。

这样的方法也能揭示问题，但当所熟悉的工具及所做的调整与问题不相关时，进展会很缓慢。这个方法用一类观测偏差来命名，这类偏差叫做街灯效应。

随机变动讹方法

这是一个实验性质的讹方法。用户随机猜测问题可能存在的位置，然后做改动，知道问题消失。为了判断性能是否已经提升，或者作为每次变动结果的判断，用户会选择一项指标进行研究，诸如应用程序运行时间、延时、操作率（每秒操作次数），或者吞吐量（每秒的字节数）。整个方法如下：

1. 任意选择一个项目做改动（例如，一项可变参数）
2. 朝某个方向做修改
3. 测量性能
4. 朝另一个方向修改
5. 测量性能
6. 步骤3或步骤5的结果是不是要好于基准值果是，保留修改并返回步骤1。

整个过程可能最终获得的调整仅适用于被测的工作负载，方法非常耗时而且可能做出的调整不能保持长期有效。例如，一个应用程序的改动规避了一个数据库或者操作系统的bug，其结果是可以提升性能，但是当这个bug被修复后，程序这样的改动就不再有意义，关键是没有人真正了解这件事情。

做不了解的改动还有另一个风险，即在生产负载的高峰期可能会引发更恶劣的问题，因此还需要准备一个回滚方案。

责怪他人讹方法

这个讹方法包含以下步骤：

1. 找到一个不是你负责的系统或环境的组件
2. 假定问题是与那个组件相关的
3. 把问题扔给负责那个组件的团队
4. 如果证明错了，返回步骤1

也许是网络问题。可以和网络团队确认一下是不是发生了丢包或其他事情

Ad Hoc核对清单法

当需要检查和调试系统时，技术人员通常会花一点实际一步步地过一遍核对清单。一个典型的场景，在产品环境部署新的服务器或应用时，技术支持人员会花半天的时间来检查一遍系统在真实压力下的常见问题。该类核对清单是Ad Hoc的，基于对该系统类型的经验和之前所遇到的问题。

问题陈述法

明确问题如何陈述是支持人员开始反映问题时的例行工作。通过询问客户以下问题来完成：

1. 是什么让你认为存在性能你问题
2. 系统之前运行的好吗/li>
3. 最近有什么改动件件载/li>
4. 问题能用延时或者运行时间来表述吗/li>
5. 问题影响其他的人和应用程序吗
6. 环境是怎么样的了哪些软件和硬件么版本怎样的配置/li>

科学法

科学法研究未知的问题是通过假设和实验。有以下步骤：

1. 问题
2. 假设
3. 预测
4. 实验
5. 分析

问题就是性能问题的陈述。从这点可以假设性能不佳的原因可能是什么。然后进行试验，可以是观测性的也可以是实验性的，看看基于假设的预测是否正确。最后是分析收集的试验数据。

诊断循环

诊断周期与科学方法相似：

假设——>仪器检验——>数据——>假设

就像科学方法一样，这个方法也通过收集数据来验证假设。这个循环强调数据可以快速地引发新的假设，进而验证和改良，以此继续。

工具法

工具为导向的方法如下：

1. 列出可用到的性能工具（可选的，安装的或者可购买的）
2. 对于每一个工具，列出它提供的有用指标
3. 对于每一个指标，列出阐释该指标可能的规则

这个视角的核对清单告诉你哪些工具能用、哪些指标能堵，以及怎样阐述这些指标。虽然这相当高效，只依赖可用的（或知道的）工具，就能得到一个不完整的系统视野，但是，与街灯讹方法类似，用户不知道他的视野不完整——而且可能自始至终对此一无所知。需要定制工具（如动态跟踪）才能发现的问题可能永远不被识别并解决。

USE方法

USE方法（Utilization Saturation and Errors Method）应用于性能研究，用来识别系统瓶颈。一言蔽之，就是：*对所有的资源，查看它的使用率、饱和度和错误 *。

这些术语定义如下：

• 资源：所有服务器物理元器件（CPU、总线、内存等）、某些软件资源也能算在内，提供有用的指标。
• 使用率：在规定的时间间隔内，资源用于服务工作的时间百分比。虽然资源繁忙，但是资源还有能力接受更多的工作，不能接受更多工作的程度被视为饱和度。
• 饱和度：资源不能再服务更多额外的工作程度，通常由等待队列。
• 错误：错误事件的个数。

某些资源类型，包括内存，使用率指的是资源所用的容量。这与基于事件的定义是不同的，一旦资源的容量达到100%的使用率，就无法接受更多的工作，资源或者会把工作进行排队（饱和），或者会返回错误，用USE方法也可以予以鉴别。

错误需要调查，因为它们会损害性能，如果故障模式是可恢复的，错误可能难以立即察觉。这包括操作失败重试，还有冗余设备池中的设备故障。

与工具法相反的是，USE方法列举的是系统资源而不是工具。

过程

下图描绘了USE方法的流程图。错误被置于检查首位，要先于使用率和饱和度。错误通常容易很快被解释，在研究其他指标之前，把它们梳理清楚是省时高效的。

指标

一旦掌握了资源列表，就可以考虑这三类指标：使用率、饱和度、以及错误。下表列举了一些资源和指标类型，以及一些可能的指标。

软件资源

某些软件资源的检测方式可能相似。这里指的是软件组件，而不是整个应用程序，如下：

• 互斥锁：锁被持有的世界是使用事件，饱和度指的是有线程排队在等待
• 线程池：线程忙于处理工作的时间是使用事件，饱和度指的是等待线程池服务的请求数目
• 进程/线程容量：系统的进程或线程的总数是有上限的，当前的使用数目是使用率，等待分配任务是饱和度，错误是分配是不
• 文件描述符容量：同进程/线程容量一样，只不过针对的是文件描述符

使用建议

对于使用上面的这些指标类型，有以下一些总体的建议：

• 使用率：100%的使用率通常是瓶颈的信号（检查饱和度并确认其影响）。使用率超过60%可能会是问题，基于以下理由：时间间隔的均值，可能掩盖了100%使用率的短期爆发，另外，一些资源，诸如硬盘（不是CPU），通常在操作期间是不能被中断的，即使做的是优先级较高的工作。随着使用率的上升，排队延时会变得更频繁和明细。
• 饱和度：任何程度的饱和度都是问题（非0）。饱和度可以用排队长度或者排队所花的时间来度量
• 错误：错误都是值得研究的，尤其是随着错误增加性能会变差的那些错误。

低使用率、无饱和、无错误：这样的反例研究起来容易。这点要比看起来还有用——缩小研究的范围能帮你快速地将精力集中在出现问题的地方，判断其不是某一个资源的问题，这是一个排除法的过程。

工作负载特征归纳

工作负载特征归纳是辨别这样一类问题简单而又高效的方法——由施加的负载导致的问题。这个方法关注于系统的输入，而不是产生的性能。

工作负载可以通过回答下列的问题来进行特征归纳：

• 负载是谁产生的程ID、用户ID、远端的IP的地址/li>
• 负载为什么会被调用码路径、堆栈跟踪/li>
• 负载的特征是什么OPS、吞吐量、方向类型（读取/写入）含变动（标准方差），如果有的话。
• 负载是怎样随着时间变化的日常模式吗/li>

向下挖掘分析

深度分析开始于在高级别检查，然后依据之前的发现缩小关注的范围，忽视那些无关的部分，更深入发掘那些相关的部分。整个过程探究到软件栈较深的基本，如果需要甚至可以到硬件层，以求找到问题的根源。

深度分析分为以下三个阶段：

1. **监测：**用于持续记录高层级的统计数据，如果问题出现，予以辨别和报警。
2. **识别：**对于给定问题，缩小研究的问题，找到可能的瓶颈。
3. **分析：**对于特定的系统部分做进一步的检查，找到问题根源并量化问题。

监测是在公司范围内执行的，所有服务器和云数据都会聚合在一起。传统的方法是使用SNMP（简单网络管理协议），监控支持该协议的网络设备。数据可以揭示长期的变化特定，这些是无法由短时间段内运行的命令行工具获得的。如果发现怀疑的问题，多数的监测方案会报警，此时及时分析并进入下一个阶段。

问题的识别在服务器上是交互执行的，用标准的观测工具来检查系统的组件：CPU、磁盘、内存等等。通常是用诸如vmstat(1)、iostat(1)和mpstat(1)这样的工具起一个命令行会话来完成的。

有些分析工具还具备tracing或profiling 的功能，用以对可疑区做更深层次的检查。做这类深层的分析可能需要定制工具乃至检查源代码。大量研究的努力就花在这里，按需要对软件栈的层次做分离来找出问题的根本原因。执行这类任务的工具包括 strace(1)、truss(1)、perf和DTrace。

五个Why：

在分析阶段，还有一个方法，叫做，“五个Why”技巧：问自己“why”后作答，以此重复五遍。下面是一个例子：

1. 查询多了数据库性能就开始变差。Why/li>
2. 由于内存换页磁盘I/O延时。Why/li>
3. 数据库内存用量变得太大了。Why/li>
4. 分配器消耗的内存比应该用的多。Why/li>
5. 分配器存在内存碎片问题。Why/li>

延时分析

延时分析检查完成一项操作所用的时间，然后把时间再分成小的时间段，接着对有着最大延时的时间段做再次的划分，最后定位并量化问题的根本原因。与深度分析相同，延时分析也会深入到软件栈的各层来找到延时问题的原因。

分析可以从所施加的工作负载开始，检查工作负载是如何在应用程序中处理的，然后深入到操作系统的库、系统调用、内核以及设备驱动。

事件跟踪

系统的操作就是处理离散的事件，包括CPU指令、磁盘I/O，以及磁盘命令、网络包、系统调用、函数库调用、应用程序事件、数据库查询，等等。性能分析通常会研究这些事件的汇总数据，诸如每秒的操作数、每秒的字节数，或者是延时的平均值。有一些重要的细节信息不会出现在这些汇总中，因此最后的研究事件的方法是逐个检查。

当执行时间跟踪时，需要找到下列信息：

• 输入：事件请求的所有属性，即类型、方向、尺寸，等等。
• 时间：起始时间、终止时间、延时（差异）。
• 结果：错误状态、事件结果（大小尺寸）。

基础线统计

把当前的性能指标与之前的数值做笔记，对分析问题常常有启发作用。负载和资源使用的变化是可见的，可以把问题回溯到它们刚发生的时候。

基础线统计包括大范围的系统观测并将数据进行保持以备将来参考。与启动以来的信息统计不同，后者会隐藏变化，基础线囊括了每秒的统计，因此变化是可见的。

在系统或应用程序变化的之前和之后都能做基础线统计，进行分析性能变化。可以不定期地执行基础线统计并把它作为站点记录的一部分，让管理员有一个参照，了解“正常”是什么样的。若是作为性能监测的一部分，可以每天都按固定间隔执行这类任务。

静态性能调整

静态性能调整处理的是架构配置的问题。其他的方法着重的是复杂施加后的性能：动态性能。静态性能分析是在系统空闲没有施加负载的时候执行的。

做性能分析和调整，要对系统的所有组件逐一确认下来问题：

• 改组件是需要的吗/li>
• 配置是针对预期的工作负载设定的吗/li>
• 组件的自动配置对于预期的工作负载是最优的吗/li>
• 有组件出现错误吗在降级状态吗/li>

下面是一些在静态性能调整中可能发现的问题：

• 网络接口选择：选择100Mb/s而不是1Gb/s。
• 建立RAID池失败。
• 使用的操作系统、应用程序或固件是旧的版本。
• 文件系统记录的尺寸和工作负载I/O的尺寸不一致。
• 服务器意外配置了路由。
• 服务器使用的资源，诸如认证，来自远端的数据中心，而不是本地的。

缓存调优

从应用程序到磁盘，应用程序和操作系统会部署多层的缓存来提高I/O的性能。下面是各级缓存的整体调优策略：

1. 缓存的大小尽量和栈的高度一样，靠近工作执行的地方，减少命中缓存的资源开销
2. 确认缓存开启并确实在工作
3. 确认缓存的命中/失效比例和失效率
4. 如果缓存的大小是动态的，确认它的当前尺寸
5. 针对工作负载调整缓存。这项工作依赖缓存的可调参数
6. 针对缓存调整工作负载。这项工作包括减少对缓存不必要的消耗，这样可以释放更多空间来给目标工作负载使用

微基准测试

微基准测试测量的是施加了简单的人造工作负载的性能。微基准测试可以用于支持科学方法，将假设和预测放到测试中验证，或者作为容量规划的一部分来执行。

下面是一些微基准测试的例子，包括一些二维测试：

• **系统调用：**针对fork()、exec()、read()、close()
• **文件系统读取：**从缓存过的文件读取，读取数据大小从1B变化到1MB
• **网络吞吐量：**针对不同的socket缓冲区的尺寸测试TCP端对端数据传输

微基准测试通常在目标系统上的执行会尽可能快，测量完成大量上述这类操作所要的时间，然后计算平均值（平均时间 = 运行时间 / 操作次数）。

建模

建立系统的分析模型有很多用途，特别是对于可扩展性分析：研究当负载或者资源扩展时性能会如何变化。这里的资源可以是硬件，如CPU核，也可以是软件，如进程或线程。

除对生产系统的观测（“测量”）和实验测试（“仿真”）之外，分析建模可以被认为是第三类性能评估方法。上述三者至少择其二可让性能研究最为透彻：分析建模和仿真，或者仿真和测量。

如果是对一个现有系统做分析，可以从测量开始：归纳负载特征和测量性能。实验性分析，如果系统没有生产环境负载或者要测试的工作负载在生产环境不可见，可以用工作负载仿真做测试。分析建模基于测试和仿真的结果，用于性能预测。

可扩展性分析可以揭示性能由于资源限制停止线性增长的点，即拐点。找到这些点是否存在，若存在，在哪里，这对研究阻碍系统扩展的性能问题有指导意义，帮助我们在碰到这些问题之前就能将它们修复。

企业 VS 云

虽然建模可以让我们不用实际拥有一个大型的企业系统就可以对其进行仿真，但是大型环境的性能通常是复杂并且难以精确建模的。

利用云计算，任意规模的环境都可以短期租用——用于基准测试。不用建立模型来预测性能，工作负载可以在不同尺寸的云上进行特征归纳、仿真和测试。某些发现，如拐点，是一样的，但现在更多地是基于测试数据而非理论模型，在真实环境中测试，就会发现一些制约性能的点并未收纳在模型里。

可视化识别

当通过实验收集到了足够多的数据结果，就可以把它们绘制成性能规模变化的曲线，这样的曲线往往可以揭示一定的规律。

Amdahl扩展定律

该定律对系统的扩展性进行了建模，所考虑的是串行构成的不能并行执行的工作负载。这个定律可以用于CPU、线程、工作负载等更多事务的扩展性研究。

Amdahl扩展定律的应用步骤如下：

1. 不论是观测现有系统，还是实验性地使用微基准测试，或者用负载生成器，收集N范围内的数据
2. 执行回归分析来判断Amdahl系数(a)的值，可以用统计软件做这件事情，如gnuplot或R。
3. 将结果呈现出来用于分析。收集的数据点可以和预测扩展性的模型函数画在一起，看看数据和模型的差别。这件事也可以用gnuplot或R来完成。

通用扩展定律

这个定律用于描述一致性扩展的曲线，竞争的影响也包含在内：

USL定义为：
C(N) = N/1 + a(N – 1) + BN(N – 1)

排队理论

排队理论是用数学方法研究带有队列的系统，提供了队列长度、等待时间（延时）、和使用率（基于时间）的分析方法。在计算领域的许多组件，无论是硬件还是软件，都能建模成为队列系统。多条队列系统的建模叫做队列网络。

排队理论是建立在数学和统计的很多领域之上的，包括概率分布、随机过程、Erlang的C公式和Little’s定律。

利用排队系统可以回答各种各样的问题，也包括下面这些问题：

• 如果负载增加一倍，平均响应时间会怎么样/li>
• 增加一个处理器对平均响应时间有什么影响/li>
• 当负载增加一倍时，系统的90%响应时间能在100ms以下吗/li>

除了响应时间之外，排队理论还研究其他因素，包括使用率、队列长度、以及系统内的任务数目。

下图中有一个单点的服务中心在处理队列里的任务。排队系统可以有多个服务中心并行地处理工作。在排队理论中，服务中心通常称为服务器。

每秒2500个请求的性能足够吗答这个问题需要理解什么是工作负载的峰值，通常按每日访问来显示。对既有系统而言，只有监视过一段时间，就应该会有峰值是什么样的概念。

想象一下一太web服务器每天处理100 000次网站点击。这看起来可能挺多的，但平均下来，差不多每秒只有一次请求——并不多。然而，可能100 000次网站点击的大多数都发生在新内容更新后的一秒，那样的话峰值就很高了。

因素分析

在购买和部署新系统时，通常由很多因素需要调整以达到理想的性能。这些调整包括磁盘和CPU的数目、RAM的大小、是否采用闪存设备、RAID的配置、文件系统设置，以及诸如此类的事情。一般用最小的成本来实现需要的性能。

对所有可能的组合做测试，可以决定哪个组合具有最佳的性价比。但是，真这样做的话很快就会失控：八中两个可能的因素就需要256次测试。

解决方法是测试一个组合的有限集合。基于对系统最大配置的了解有下面这么一个方法：

1. 测试所有因素都设置为最大时的性能
2. 逐一改变因素，测试性能（应该是对每一个因素的改动都会引起性能下级）
3. 基于测量的结果，对每个因素的变化引起性能下级的百分比以及所节省的成本做统计
4. 将最高的性能和成本作为起始点，选择能节省成本的因素，同时确保组合后的性能下降仍满足所需的每秒请求数量
5. 重新测试改变过的配置，确认所交付的性能

扩展方案

要满足更高的性能需要，常常意味着建立更大的系统，这种策略叫做垂直扩展。把负载分散给许许多多的系统，在这些系统前面放置负载均衡器，这让系统看起来像是一个，这种策略叫做水平扩展。

统计

理解如何使用系统统计并且了解统计的局限性是很重要的。

量化性能

要比较问题和对与问题排优先级，需要对问题和问题修复后所带来的性能潜在提升做量化。这件事情一般用观测或者实验的方式做。

基于观测：用观测法量化性能问题

1. 选择可靠的指标
2. 估计解决问题带来的性能收益

平均值

平均值就是用单个数据代表一组数据：数据集中趋势的指标。最常见的平均值类型是算术平均值，就是数据的总值除以数据的个数。其他的均值类型还有几何平均值和调和平均值。

标准方差、百分位数、中位数

标准方差和百分位数是提供分布数据信息的统计技术。标准方差是数据的离散程度，更大的数值表示着数据偏离均值的程度越大。

文章知识点与官方知识档案匹配，可进一步学习相关知识CS入门技能树Linux入门初识Linux24884 人正在系统学习中

来源：程序猿加油站