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

前言

性能是一门令人激动的，富于变化同时又充满挑战的学科。

系统性能

系统性能是对整个系统的研究，包括了所有的硬件组件和整个软件栈。所有数据路径上和软硬件上所发生的事情都包括在内，因为这些都有可能影响性能。对于分布式系统说，这意味着多台服务器和多个应用。

下图呈现的是单台服务器上的通用系统软件栈，包括操作系统（OS）内核、数据库和应用程序层。术语”全栈“（entire stack）有时一般仅仅指的是应用程序环境，包括数据库、应用程序、以及网站服务器。不过，当论及系统性能时，用全栈来表示所有事情，包括系统库和内核。

人员

系统性能是一项需要多类人员参与的事务，其中包括运维、架构师、开发者、数据库管理员、网络管理员。对于他们的大多数来说，性能是一项兼职的事情，他们可能会有发掘性能的倾向，但仅限于本职工作范围内（网络团队检查网络、数据库团队检查数据库，架构师检查架构等等）。然而，对于某些性能问题，要找到根本原因还需要这些团队一起协同工作才行。

一些公司会雇佣性能工程师，其主要任务就是维护系统性能。他们与多个团队协同工作，对环境做全局性的研究，对整个环境做系统级分析，为容量规划定义指标。

在性能领域也有某些专职与特定应用程序的工种，例如，go性能工程师和MySQL性能工程师。通常他们在开始使用特定的应用程序工具之前，会做一些系统性能检查，但是有限。

事情

性能领域包括了以下的事情，按照理想的执行顺序将它们排列如下：

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

步骤1~5是传统软件产品开发过程的一部分。产品发现之后，接下来要么是在生产环境中进行概念验证测试，要么直接进行部署和配置。如果再生成环境中配到问题（步骤6-9），这说明该问题在软件开发阶段没有得到发现和修复。

术语容量规划（capacity planning）指的是一系列事情行动。在设计阶段，包括通过研究开发软件的资源占用情况，来得知原有设计在多大程度上能满足目标需求。在部署后，包括监控资源的使用情况，这样问题在出现之前就能被预测。

视角

与很多事情专注于一点不同，性能是可以从不同的视角来审视。下图展示了两种性能分析的视角：负载分析（workload analysis）和资源分析（resource analysis），二者从不同的方向对软件栈做分析。

系统管理员作为系统资源负责人，通常采用资源分析视角。应用程序开发人员，对最终实现的负载性能负责，通常采用负载分析视角。每一种视角都有自身的优势。尝试从这两个视角都进行分析，对于解决某些具有挑战性的问题是无不裨益的。

性能是充满挑战

系统性能工程是一个充满挑战的领域，具体原因有很多，其中包括以下事实，系统性能是主观的、复杂的，而且常常是多问题并存的。

性能是主观的

在进行软件故障查找的时候，判断bug是否存在或bug是否修复就是这样。bug的出现总是伴随着错误信息，错误信息通常容易解读，进而就明白错误为什么出现了。

与此不同，性能常常是主观性的。开始着手性能问题的时候，对问题是否存在的判断都有可能是模糊的，在问题被修复的时候也同样，也被一个用户认为是”不好“的性能，另一个用户可能认为是”好“的。

考虑下面的信息：

• 磁盘的平均I/O 响应时间是1ms。

这是”好“还是”坏“？响应时间或者说是延时，虽然作为最好的衡量指标之一，但还是难以用来说明延时的情况。从某种程度上说，一个指标是”好“或”坏“取决于应用开发人员和最终用户的性能预期。

通过定义清晰的目标，诸如目标平均响应时间，或者对落进一定响应延时范围内的请求统计其百分比，可以把主观的性能变得客观化。

性能是复杂的

除了主观性之外，性能工程作为一门充满了挑战的学科，除了因为系统的复杂性，还因为对于性能，我们常常缺少一个明确的分析起点。有时我们只是从猜测开始，比如，责怪网络，而性能分析必须对这是不是一个正确的放心做出判断。

性能问题可能出在子系统之间复杂的互联上，即使这些子系统隔离时表现得都很好。也可能由于连锁故障出现性能问题，这指的是一个出现故障的组件会导致其他组件产生性能问题。要理解这些产生的问题，就必须理清组件直接的关系，还要了解它们是怎样协作的。

瓶颈往往是复杂的，还会以意想不到的方式互相联系。修复了一个问题可能只是把瓶颈推向了系统里的其他地方，导致系统的整体性能并没有得到期望的提示。

除了系统的复杂性之外，生成环境负载的复杂特性也可能会导致性能问题。在测试环境很难重现这类情况，或者只能间歇式地重现。

解决复杂的性能问题常常需要全局性的方法。整个系统——包括自身内部和外部的交互都可能需要被调查研究。这个要求有非常广泛的技能，一般不太可能集中在一人身上，这促使性能工程成为一门多变的并且充满智力挑战的工作。

可能有多个问题并存

找到一个性能问题点往往并不是问题本身，在复杂的软件中通常会有多个问题。即使是那些被认为拥有高性能的软件，也会有不少已知的但仍未被修复的性能问题。这就造成了性能分析的又一个难度：真正的认为不是寻找问题，而是辨别问题或者说是辨别哪些问题是最重要的。

要做到这一点，性能分析必须量化问题的重要程度。某些性能问题可能并不适用于我们的工作或者只在非常小的程度上适用。理想情况下，我们不仅要量化问题，还要估计每个问题修复后能带来的增速。当管理层审查工程或运维资源的开销缘由时，这类信息尤其有用。

有一个指标非常适合用来量化性能，那就是延时（latency）

延时

延时测量的是用于等待的时间。广义来说，它可以表示所有操作完成的耗时，例如，一次应用程序请求、一次数据库查询、一次文件系统操作，等待。例如，延时可以表示从点击链接到屏幕显示整个网页加载完成的时间。这是一个对于用户户和网站提供商来说都非常重要的指标：高延时会令人沮丧，客户可能会选择到别处开展业务。

动态跟踪

动态跟踪技术把所有的软件变得可以监控，而且能用再真实的生成环境中。这是利用内存中的CPU指令并在这些指令上动态构建检测数据。这样从任何运行的软件中都可以获得定制化的性能统计数据，从而提供了远超系统的自带统计所能给予的观测性。