• 性能优化方法：包括响应时间和吞吐量优化，以及基准测试、容量规划、垂直和水平扩展等方面的优化方法。
• 系统架构设计：包括分层架构、微服务架构、事件驱动架构、云原生架构等，以及它们的优缺点和适用场景。
• 操作系统和计算机体系结构：包括CPU、内存、缓存、磁盘、网络等硬件和操作系统相关的知识，以及如何优化它们的性能。
• 数据库和存储系统：包括关系型数据库、NoSQL数据库、内存数据库、文件系统等，以及它们的优缺点和适用场景。
• 分布式系统：包括分布式存储、分布式计算、分布式事务等，以及如何处理分布式系统中的并发和一致性问题。
• 云计算和容器技术：包括公有云、私有云、混合云等云计算部署模型，以及Docker、Kubernetes等容器技术的基本概念和使用方法。
• 网络和协议：包括TCP/IP协议、HTTP协议、WebSocket协议等，以及如何诊断和优化网络问题。
• 性能工具和监控：包括负载测试工具、性能监控工具、日志分析工具等，以及如何使用这些工具来诊断和解决性能问题。
• 安全和可靠性：包括如何保证系统的可用性、可靠性和安全性，以及如何应对各种安全和可靠性威胁。
• DevOps和敏捷开发：包括DevOps和敏捷开发的基本概念、实践和工具，以及如何将它们与性能优化和系统设计相结合。

第一部分：性能指标与性能分析

• 第1章：性能指标和性能评估
• 第2章：性能分析的基础
• 第3章：性能基准测试

第一部分的重点是关于性能测量的基本原理和工具，涵盖以下几个方面：

1. 性能测量的基本原理：Brendan Gregg在本书中介绍了性能测量的四个基本原则，即测量、分析、比较和验证[1]。
2. 性能测量的基本工具：本书介绍了多种性能观测工具，包括计数器、跟踪器和剖析器等。其中，计数器是内核维护的统计数据，可以用于对事件计数[3]。
3. 火焰图：本书介绍了火焰图作为一种常用的性能分析工具，可以用于可视化代码的执行过程，并识别瓶颈[2]。
4. 其他工具和技术：本书还介绍了其他性能观测工具和技术，如dtrace、perf等，并提供了相应的实例和使用方法。

综上所述，第一部分主要介绍了性能测量的基本原理和工具，包括计数器、跟踪器和剖析器等，同时也介绍了火焰图作为一种常用的性能分析工具，以及其他工具和技术。

第二部分：系统性能

• 第4章：操作系统的性能
• 第5章：存储系统的性能
• 第6章：网络性能

第三部分：企业应用性能

• 第7章：企业应用性能基础
• 第8章：Java虚拟机性能
• 第9章：数据库性能
• 第10章：Web应用程序性能

第四部分：云计算性能

• 第11章：云计算的性能挑战
• 第12章：云服务的性能分析
• 第13章：云应用程序性能

第五部分：性能优化

• 第14章：系统和应用程序性能优化
• 第15章：云环境中的性能优化

频次最高的10个分析工具或命令：

1. top：用于查看系统中运行的进程和资源占用情况的命令行工具。
2. sar：系统活动报告工具，用于收集和报告系统资源使用情况的命令行工具。
3. strace：用于跟踪进程系统调用和信号的命令行工具。
4. tcpdump：用于捕获和分析网络数据包的命令行工具。
5. Wireshark：网络协议分析工具，用于分析和调试网络通信的图形化工具。
6. perf：Linux性能事件分析工具，用于分析CPU、内存和I/O等性能事件的命令行工具。
7. lsof：列出打开文件的工具，用于显示系统中打开的文件和进程的命令行工具。
8. ps：查看系统进程的命令行工具。
9. iostat：输入/输出统计工具，用于监控系统磁盘和存储性能的命令行工具。
10. vmstat：虚拟内存统计工具，用于监控系统内存和CPU使用情况的命令行工具。

综述

1.1 系统性能

（图 1.1 系统性能-通用软件栈）

• 整个系统的研究：所有的硬件组件和整个软件栈。
• 所有数据路径、软硬件上所有的事情都会影响性能。
• 当讨论到系统性能，全栈表示所有事情，包括系统库及内核。

“全栈”（entire stack）有时一般仅仅指的是应用程序环境，包括数据库、应用程序，以及网站服务器。”

1.2 人员与职能

• 一般人员配置都是兼职 对性能问题的解决，这样出现问题需要很多职能的人协作解决。
• 有的公司会请 性能工程师，其主要任务就是维护系统性能。
  • 他们与多个团队协同工作
  • 对环境做全局性的研究
  • 执行一些对解决复杂性能问题至关重要的操作。
  • 会开发更好的工具
  • 对整个环境做系统级分析（system-wide analysis）
  • 为容量规划（capacity planning）定义指标
• 性能工程师也有精细到应用程序（mysql性能工程师、java性能工程师等）的工种，通常他们在开始使用特定的应用程序工具之前，会做一些系统性能检查，但是有限。

1.3 性能领域的事情

（图 1.3 事情）

1.设置性能目标和建立性能模型 2.基于软件或硬件原型进行性能特征归纳 3.对开发代码进行性能分析（软件整合之前） 4.执行软件非回归性测试（软件发布前或发布后） 5.针对软件发布版本的基准测试 6.目标环境中的概念验证（Proof-of-concept）测试 7.生产环境部署的配置优化 8.监控生产环境中运行的软件 9.特定问题的性能分析

• 1～5 常见的软件开发过程，这个阶段经常缺失性能设计，从而导致6～9节点在客户环境中出现“未知”的性能问题。
• 当没有性能设计参与的架构，后期出现的性能问题修复难度会越来越大。
• 因为缺乏设计，所以没有目标，没有目标，监控就容易丢失重心。
• 在设计阶段对开发软件的资源占用情况进行研究，得以进一步确认最初性能设计与性能目标的偏差程度。在部署后，监控资源的使用情况，可以在问题出现之前就被发现。 容量规划（capacity planning）指的是一系列事前行动

1.4 视角

图 视角

负载分析 （workload analysis） 一般系统管理员会从这个视角进行分析

资源分析 （resource analysis） 一般开发人员会从这个视角进行分析

1.5 性能是充满挑战的

1.5.1 性能是主观的

• 已经存在的客观事实，在没有明确的期望性能目标时，很难断定其“好”或“坏”。
• 需要方法将性能客观化。

1.5.2 性能是复杂的

• 系统的复杂性，组件的关联。
• 常常缺少一个明确的分析起点。
• 瓶颈往往是复杂的，看似解决了瓶颈，可能只是将瓶颈推向了系统的其他地方，从而导致整体系统性能没有提升。
• 环境很难复现，或只能间歇式重现。

1.5.3 可能多个问题并存

• 成熟的软件，即便是那些被认为拥有高性能的软件，也会有不少已知的但未被修复的性能问题。
• 真正的任务不是寻找问题，而是辨别问题或者说是辨别哪些问题是最重要的。
• 识别“最重要的”，意味着性能分析要对问题的重要程度进行“量化”（quantify）。
• 理想情况：1. 量化问题 2. 估计每个问题修复后带来的增速。
• 延时（latency）这个指标非常适合量化性能。

1.6 延时 Latency

• 延时 = 等待时间
• 广义：所有操作完成的等待时间
• 延时可以估计最大增速（maximum speedup）。

1.7 动态跟踪 dynamic tracing

• 动态跟踪可以从任意感兴趣的点测量延时（latency），并且提供数据以显示延时完整的分布情况。
• dynamic tracing 可以把所有软件变得可以监控。
• 可以在真实的生产环境中使用。
• 比“内核分析”更方便的对延时建立测量监控。
• Dtrace 对用户态和内核态的软件都提供了静态跟踪和动态跟踪

1.8 云计算

• 虚拟化
• 快速扩展成为可能
• 降低了容量规划的精度要求
• 性能分析需求要求更高
• 性能隔离（performance isolation）带来的性能影响

1.9 案例

方法

2.1 术语

IOPS: 每秒的输入输出次数。对于硬盘，每秒的读写次数。数据传输的度量方式。

吞吐量：数据传输速度（字节/秒或比特/秒）。工作执行速率。数据库下，指操作的速度（每秒操作数或每秒业务数）。

响应时间：一次操作完成时间。

延时：操作里用来等待服务的时间。操作执行之前所花费的时间。在某些情况，等同于 响应时间。

使用率：对于服务所请求的资源，在给定时间区间内资源的繁忙程度。对于存储资源来说，使用率指的就是所消耗的存储容量（内存使用率）。

饱和度：指的是某一资源无法满足服务的排队工作量。

瓶颈：在系统性能里，瓶颈指的是限制系统性能的那个资源。分辨和移除系统瓶颈是系统性能的一项重要工作。

工作负载：系统的输入或者是对系统所施加的负载叫做工作负载。对于数据库来说，工作负载就是客户端发出的数据库请求和命令。

缓存：用于复制或者缓冲一定量数据的高速存储区域，目的是为了避免对较慢的存储层级的直接访问，从而提高性能。出于经济考虑，缓存区的容量要比更慢一级的存储容量要小。

2.2 模型

这些模型阐述了一些性能基本原则：

2.2.1 受测系统 SUT - System Under Test

图

扰动会影响结果

• 扰动：定时执行的系统活动、系统的其他用户以及其他的工作负载
• 从单个客户的SUT的视角无法观察到物理宿主系统的其他活动（由其他租户引起的）

2.2.2 排队系统

图 详见 2.6

2.3 重要概念（概括）

概括描述，详细会在其他章节的分析部分。

2.3.1 延时

• 操作执行之前所花费的时间。例如：这个操作用来数据传输，而这个操作执行之前必须先建立连接，这个建立连接的过程就是延时。
• 性能问题可以用延时来进行量化和评级，因为延时都用的是相同的单位来表达。IOPS就不行。
• 通过考量所能减少或移除的延时，预计的加速也可以计算出来。
• 如果是100个网络I/O和50个磁盘I/O做选择，是一个非常复杂的选择，如果是100ms网络I/O，50ms的磁盘I/O就很简单。尝试将其他指标都转为延时或时间，这样更容易比较。

2.3.2 时间量级

用数字来作为时间的比较方法，同时可以用时间的长短经验来判断延时的源头。

CPU循环和延时 参考 第6章，第9章 互联网延时 参考第10章

2.3.3 权衡三角

图

CPU与内存之间的权衡：内存缓存数据结果，降低CPU的使用。在CPU充足的情况下，CPU可以压缩数据来降低内存的使用。

文件系统记录尺寸（或块的的大小）：小的记录尺寸，接近应用程序I/O大小，随机I/O工作负载会有更好的性能，程序运行的时候能更充分地利用文件系统的缓存。选择大的记录尺寸能提高流的工作负载性能，包括文件系统的备份。

网络缓存尺寸：小的网络缓存尺寸会减小每一个连接的内存开销，有利于系统扩展，大的尺寸能提高网络的吞吐量。

2.3.4 调整的影响

• 性能调整发生在越靠近工作执行的地方效果最显著。
• 应用程序层级的调整，可能通过消去或减少数据查询获得很大的性能提升（例如，20倍）。
• 存储设备层级的调整，可以精简或提高存储I/O，但是性能提升的大头在更高层级的系统栈代码-，所以调整得到的性能提升有限，时百分比量级（例如，20%）

调整事例

• 在应用程序层级的调整效果最显著，但不是观测效果最显著的层级。
• 数据查询慢要从其花费的CPU时间、文件系统和所执行的磁盘I/O方面来考察最好。
• 操作系统的性能分析能辨别出来的不仅是操作系统层级的问题，还有应用程序层级的问题，在某些情况下，甚至要比应用程序视角还简单。

2.3.5 合适的层级

不同的公司和环境对性能有着不同的需求，这取决于性能技术投入的投资回报率（ROI）。 例如：有的公司（纽约交易所与伦敦交易所）会投入3亿美金建立横跨大西洋的光缆，是为了减少6ms的的传输延时。

2.3.6 性能建议的时间点

性能配置不是所有时间点都有效。无法一劳永逸。

2.3.7 负载 vs.架构

图 性能差可能是来自软件配置和硬件，也有可能是架构问题，此外还有可能是太多的负载，而导致了排队和长延时。

2.3.8 扩展性

图 吞吐量 vs.负载

理想阶段：扩展性是线性变化的（吞吐量随着负载的增加而增加）。 拐点阶段：当到达拐点的时候，资源的争夺开始影响性能，此时扩展性将无法在保持线性发展，内聚性导致完成的工作变少而且吞吐量也减少了。 饱和点：当组件使用率达到100%或接近100%时，排队频繁且比较明显。 例如，当程序是一个大量计算的应用程序（负载由线程承担），当cpu接近100%使用率时，延时增大，性能开始下降。当把x轴换成”CPU“，和上图的曲线会一致。

图 性能下降

性能的非线形变化，用平均响应时间或延时来表示。

• 性能”快速“下降可能是由于内存的负载：当系统开始换页（或者使用swap）来补充内存的时候。
• 性能”慢速“下架可能是由于CPU的负载。
• 性能”快速“下降可能是由于磁盘I/O：随着负载（和磁盘使用率）的增加，I/O可能会排队。空闲的旋转的磁盘可能I/O服务响应时间约1ms，但是当负载增加，响应时间会变成10ms。可以查看2.6.5的模型，在M/D/1和60使用率情况下的表现。

如果资源不可用，应用程序开始返回错误，响应时间是线性变化的。例如：web服务器的503，而不是添加请求到排队队列中，这样的服务能用始终如一的响应时间来执行。

2.3.9 已知的未知

• 已知的已知：有些东西你知道。例如：你知道你要检查性能指标，如CPU使用率，并且你也知道当前的均值是10%。
• 已知的未知：有些东西你知道你不知道。例如：你知道你能用profiling检查是什么致使CPU忙碌，但你还没有去做这件事。
• 未知的未知：有些东西你不知道你不知道。举个例子，你可能不知道设备终端可以消耗大量CPU资源，因此你对此并不做检查。

图

性能领域是”你知道的越多，你不知道的也就越多“。和学习系统是一样的原理：你了解的越多，就意识到”未知的未知“就越多，然后这些”未知的未知“就变成了”已知的未知“。

2.3.10 指标

IOPS 度量的是吞吐量，但只针对I/O操作（读取和写入）。

上下文很关键，上下文不同，定义可能会不同。

开销：性能指标不是免费的，在某些时间后会消耗一些CPU周期来收集和保存指标信息。对目标的性能会有负面影响，这种影响被称为观察者效应（observer effect）。“（这通常与海森堡测不准原理混淆，后者描述的是对于互为共轭的物理量所能测量出的精度是有限的，诸如位置和动量。）”

问题：我们总是倾向于软件商提供的指标是经过仔细挑选，没有bug，并且具有很好的可见性。但事实上，这些指标可能是混淆的、复杂的、不可靠的、不精确的、甚至是错的（bug导致）。更多参见第4章。

2.3.11 使用率

使用率经常用于系统描述设备的使用情况。 使用率是基于时间或者容量的。 使用率告诉我们组件的忙碌程度。

基于时间

基于时间的使用率是使用排队理论做正式定义的。

例如 Gunther 97 : 服务器或资源繁忙时间的均值，相应的比例公式是 U = B/T U：使用率 T：观测周期 B：T时间内系统的繁忙时间

iostat(1)调用的指标%b,即忙碌百分比，能很好表现 “U=B/T”的本质。

组件A 100%使用率，并且该组件关联的系统性能严重下降，检查该系统的其他组件指标，确认该组件是不是成了整体的性能瓶颈。

有些组件在使用率100%的情况下，性能不会下降的很厉害。比如：能够并行地为操作提供服务的组件。

电梯在载人过程中（100%使用率），依然可以继续接收更多乘客。

100%忙碌的磁盘也能够接受并处理更多的工作，例如，通过把写入的数据放入磁盘内部的缓存中，稍后再完成写入，就能做到这点。通常存储序列运行在100%的使用率是因为其中的某些磁盘在100%忙碌时，序列中依然有足够的空闲磁盘来接受更多的工作。

基于容量

系统或组件（例如硬盘）都能够提供一定数量的吞吐。无论性能处于何种级别，系统或组件都工作在其容量的某一比例上。这个比例就称为使用率。

如果是容量的使用率，硬盘的100%意味不能接受更多工作。 如果是时间的使用率，硬盘的100%意味着时间上的忙碌，但可能接受更多任务。

100%忙碌（时间）不意味着100%的容量使用。

一般来说描述的使用率都是基于时间的。

非空闲时间

如何定义使用率，用上述定义可能会混淆，可尝试使用新词“非空闲时间”，这样描述更精准，但是没有普及。

2.3.12 饱和度

饱和度：随着工作量增加而对资源的请求处理超过资源所能处理的程度。 发生在100%使用率（基于容量）时，无法处理时，将进行排队。

图

当达到100%使用率时，随着负载增加，饱和度线性增加。 出现饱和度，意味着排队等待（延时），即是性能问题。

如果是基于时间的使用率达到100%不意味着会发生饱和度，这取决于资源处理任务的并行能力。

2.3.13 刨析 Profiling

刨析本意指对目标对象的研究和理解。

计算机性能领域，profiling 按照特定的时间间隔对目标（系统状态）进行采样，然后对采样进行研究。

2.3.14 缓存

缓存被频繁用来性能提升。 把磁盘的块缓存在主内存（RAM）。 一般使用多层缓存。 CPU 主缓存（L3 < L2 < L1）。L2 和 L3 逐渐增加了容量及延时，这是一种经济上的权衡。

缓存性能重要指标，命中率：

命中率 = 命中次数（hits） / （ hits + 未命中次数（misses））。

图

98%和99%之间的性能差异要比10%和11%之间的性能差异大很多。这取决于缓存的存储层次的速度差异，存储层级速度差异越大，曲线倾斜越陡峭。

缓存另一个指标，失效率：每分钟缓存失效的次数。 缓存失效和性能是线性。

例A： 工作负载A的命中率90%，失效率200/s。 工作负载B的命中率80%，失效率20/s。 哪个性能更好？

工作负载总的运行时间：

运行时间= （命中率 * 命中延时）+（失效率 * 失效延时）

这里用的是平均命中延时和平均未命中延时，并且假定工作是串行发生的。

算法

MRU（最近最常使用算法）：指的是一种缓存保留策略，决定最新使用次数最多的数据进行保留。 LRU（最新最少使用算法）：指的是一种回收策略，决定最近使用次数最少的数据进行回收。 MFU（最常使用算法）： LFU（最不常使用算法）： NFU（不常使用算法）：是LRU的一个花费不高但吞吐量稍小的版本。

缓存的热、冷和温

缓存的状态：

冷：命中率为0（或接近0，当它开始变暖的时候）。是空的，或填充的是无用数据。 热：命中率超过99%。填充的是常用数据，或有着很高的命中率。 温：填充了有用的数据，但命中率没有达到预想的高度。 热度：缓存的热度或冷度。提高热度的目的就是提高缓存的命中率。

如果缓存较大或下一级的存储较慢（或者两者皆有），会需要一段较长的时间来填充缓存使其变暖。

例如：

• 128GB（DRAM），600GB（闪存）二级缓存，物理磁盘做存储。
• 在随机读的负载下，磁盘 IOPS：2000次读。一次I/O(读）：8KB。
• 缓存变暖的速度仅有 16MB/s（2000 * 8KB）。
• 两级缓存从冷开始，需要2小时来让DRAM变温，需要最少10小时让闪存变暖。
• 2.28小时（128 * 1024 / 16 * 60 * 60 ）达到 100%

2.4 视角

工作负载：在上而下 资源分析：在下而上

2.4.1 资源分析

• 性能问题研究：看是否某特定类型资源的责任。
• 容量规划：为设计新系统提供信息，或者对系统资源何时会耗尽做预测。

着重使用率的分析，判断资源是否已经处于极限或者接近极限。

适合的资源分析的指标如下：

• IOPS
• 吞吐量
• 使用率
• 饱和度

上述指标在给定负载的情况下，显示了使用程度及饱和程度（上述指标度量了在给定负载下资源所做的事情，显示资源的使用程度乃至饱和的程度）。

其他类型的指标，包括延时，也会被使用，来度量资源于给定工作负载的响应情况。

统计工具：vmstat、iostat、mpstat。

2.4.2 工作负载分析

检查应用程序的性能：所施加的工作负载和应用程序是如何响应的。

图

分析的对象如下：

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

适合分析的指标：

• 吞吐量
• 延时

这些指标分别度量了请求量的大小和在其之下系统表现出的性能。

2.5 方法

讹方法（anti-methodologies）

系统性能分析和性能调整方法：

2.5.1 街灯讹方法

这个方法用一类观测偏差来命名，这类偏差叫做街灯效应。

一天晚上，一个警察看到一个醉汉在路灯下的地面上找东西，问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到，就问他：“你确定你钥匙是在这儿丢的，就在路灯下？”醉汉说：“不，但是这儿的光是最亮的”。

这相当于查看top，不是因为这么做有道理，而是不知道什么使用其他工具。

2.5.2 随机变动讹方法

实验性质的讹方法。

操作：

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

此方法非常耗时，而且不一定能长期有效，过程还可能产生更严重的问题。

2.5.3 责怪他人讹方法

步骤：

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

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

这个讹方法只是因缺乏数据而造成的无端臆想。

2.5.4 Ad Hoc 核对清单法

基于对该系统类型的经验和之前所遇到的问题。

例如：核对清单的一项：“运行iostat -x 1 检查await 列。如果该列在负载下持续超过10（ms），那么说明磁盘太慢或是磁盘过载。”

这类清单能在最短的时间内提供最大的价值，是即时建议而且需要频繁更新以保证反应当前状态。

清单需要写的清楚且规范，说明如何辨别每个问题和如何修复。

2.5.5 问题陈述法

询问客户以下问题来完成：

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

询问上述问题过程中通常会立即指向一个根源和解决方案。 当遇到一个新的问题，首先应该使用这个方法。

2.5.6 科学法

假设和实验来研究未知问题

步骤：

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

2.5.7 诊断循环

与科学法相似： 假设 -> 仪器检验 -> 数据 -> 假设

2.5.8 工具法

2.5.9 USE方法

Utilization、saturation、errors

对于所有的资源，查看它的使用率、饱和度和错误。

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

2.5.10 工作负载特征归纳

谁？：谁产生，用户ID? 远程IP地址？进程ID？ 为什么？：会调用？代码路径、堆栈跟踪？ 怎么？：怎么变化的？有规律？ 什么？：特征是什么？IOPS？变动（标准方差）？

最好的性能来自消灭不必要的工作。

如果被识别的问题无法解决，那么可以用系统资源控制来限制它。

除了识别问题，工作负载特征归纳可以用于输入仿真基准设计。

通过此方法辨别负载问题，有利于将负载问题和架构问题区分。2.3有介绍。

此方法使用的工具视目标而定。比如：用户活动信息作为统计分析的来源。

2.5.11 向下挖掘分析

2.5.12 延时分析

2.5.13 R方法

针对Oracle数据库的性能分析方法。

2.5.14 事件跟踪

例如：tcpdump

tcpdump -ni eth0 -ttt

-ttt 输出所包含的DELTA时间，测量了包和包之间的时间。

2.5.15 基础线统计

2.5.16 静态性能调整

2.5.17 缓存调优

2.5.18 微基准测试

测量的是施加了简单的人造工作负载的性能。

可以用于支持科学方法，将假设和预测放到测试中验证，或者作为容量规划的一部分来执行。

可以用微基准测试工具来测试工作负载并度量性能。

可以用负载生成器来产生负载，用标准的系统工具来测量性能。

最稳妥：微基准测试工具第一轮测试，标准系统工具第二轮测试（确认性能数据）

微基准测试例子：

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

测量完成大量上述这类操作所要的时间，然后计算均值（平均时间 = 运行时间/操作次数）。

更多详见12章。

2.6 建模 （系统的分析模型）

可扩展性分析：建模可以用以研究当负载或资源扩展时性能会如何变化。可扩展性分析揭示拐点。

拐点：性能由于资源限制停止线性增长的点。

性能评估方法（三大类）：

• 生产环境的观测：“测量”。
• 实验性测试：”仿真“。
• 分析建模。

以上三者至少择其二可让性能研究最为透彻。

• 对现有系统：从测量开始，归纳负载特征和测量性能。
• 系统没有生产环境负载/要测试的工作负载在生产环境不可见：工作负载仿真做测试。

详见“工作负载特征归纳”、“微基准测试”。

2.6.1 企业 vs.云

利用云计算技术，任意规模的环境都可以短期租用用于基准测试仿真。

2.6.2 可视化识别

数据可视化可以从其看到规律。

图 X是扩展的维度，Y轴是相应的性能（吞吐量、每秒事务数，等等）。

曲线类型如下：

• 线性扩展：性能随资源扩展成比例增长。这种情况并非永久持续，但这可能是其他扩展情况的早期阶段。
• 竞争：架构的某些组件是共享的，而且只能串行使用，共享资源的竞争会减少资源扩展的收益。
• 一致性：要维持数据的一致性，传播数据变化的代价会超过扩展带来的好处。
• 拐角：某个因素碰到了扩展的制约点，从而改变了扩展的曲线。
• 扩展上限：到达了硬性的极限。极限可能是设备瓶颈。诸如总线或互联器件到了吞吐量的最大值，或者是一个软件设置的限制（系统资源控制）。

2.6.3 Amdahl 扩展定律

该定律主要考虑串行构成的工作负载（不能并行执行）。 该定律可以用于CPU、线程、工作负载等更多事务的扩展性研究。

C(N) = N/1 + a(N - 1)

C(N): 容量 N：扩展纬度，CPU数量或用户负载。 a: 串行程度,即偏离线性扩展的程度。0 <= a <= 1 。

应用步骤：