接上篇：Thinking Clearly about Performance (Part 1)
效率
即使整个系统中的每个人都在遭受痛苦，你仍然应该首先关注业务需要第一个改进的程序。首先确保程序尽可能高效地工作。在不增加容量和不牺牲所需的业务功能的情况下，效率与任务执行的总处理时间成反比。
换句话说，效率与滥用成反比。以下是数据库应用中常见的一些滥用的示例：
- 中间层程序为每一行插入到数据库的数据创建一条不同的SQL语句。它本可以用一个
prepare调用（从而减少9999次网络I/O调用）完成任务，却执行10000次数据库prepare调用（因而产生10000次网络I/O调用）。 - 中间层程序执行100次数据库 fetch 调用（因而产生100次网络I/O调用）以获取994行数据。它本可以用10次 fetch 调用获取994行数据（从而减少90次网络I/O调用）。
- 一条SQL语句访问数据库缓存7428322次以返回698行的结果集。添加一个筛选谓词返回最终用户真正希望看到的7行，可以只访问数据库缓存52次。（选择该措辞是彻底的泄密：我是在 Oracle 社区初次了解 SQL 的）
当然，如果一个系统存在一些全局性问题，导致整个系统中的大量任务效率低下（例如，考虑不周的索引、设置错误的参数、配置不当的硬件），那么你应该改进它。但是，不要调整系统以适应效率低下的程序。（诚然，有时你需要止血带来防止流血致死，但不要把权宜之计作为永久解决办法解决效率低下的问题。）有很多手段可以解决项目效率低下的问题。即使是现有的商业化应用，与软件供应商合作以使程序高效，而不是效率低下的试图优化系统使其尽可能高效，从长远来看对你的益处更大。
提高程序效率的改进可以为系统中的每个人带来巨大的好处。不难看出最大程度减少滥用是如何帮助改进任务的响应时间的。许多人也不明白的是，提高一个程序的效率会给该系统中与被改进程序没有明显关系的程序带来性能改进方面的负面影响。出现这种情况是因为 负载 对系统硬件的影响
负载
负载是由并发任务执行引起的资源的竞争。这就是为什么软件开发人员所做的性能测试，不能捕捉到生产后期出现的所有性能问题。
负载的一个度量是利用率，即在指定的时间间隔内，资源利用率除以资源容量。随着资源利用率的提高，用户向该资源请求服务的响应时间也会增加。任何一个在大城市的交通高峰时期乘坐过汽车的人，都经历过这种现象。当交通非常拥挤时，你必须在收费站等更长的时间。
使用的软件实际上并不像车那样“变慢”。在公路上以60英里每小时的速度，而在拥挤的交通中只能每小时30英里的速度行驶。无论发生什么情况，计算机软件总是以相同的速度运行（每个时钟周期的指令数是恒定的），但是随着系统上的资源越来越繁忙，响应时间肯定会变差。
当负载增加时，系统变慢有两个原因：排队延迟和一致性延迟。
排队延迟
负载和响应时间之间的数学关系是众所周知的。一种数学模型称为 M/M/m，在满足一些特定要求时，将响应时间与系统负载相关联[11]。M/M/m 的一个假设是，所建模的系统具有“理论上完美的可扩展性”。类似于拥有一个“无摩擦”的物理系统，物理入门课程中的许多问题都基于该假设。
尽管有一些过激的假设，比如 “完美可扩展性”，M/M/m 在性能方面仍有很多东西值得学习。Figure 4 展示了 M/M/m 响应时间和负载之间的关系。
Figure 4，你可以从数学角度看到，在不同负载条件下使用系统时的感受。在低负载时，响应时间与空载时的响应时间基本相同。随着负载的增加，会感觉到响应时间有平缓的略微的变差。这种逐渐的变差并不会造成多大的危害，但是随着负载的不断增加，响应时间开始某种意义上快速的剧烈的变差。在某种程度上来说，响应时间变差变得相当令人不快，并且事实上变成了抛物型的。
在完美可扩展 M/M/m 模型中，响应时间（R）由两部分组成：处理时间（S）和排队延迟（Q），或 R=S+Q。处理时间是任务消耗给定资源的持续时间，以每次任务执行的时间为单位，例如以每次单击的秒数为单位。排队延迟是任务在给定资源处排队，等待消耗该资源的条件满足的时间。排队延迟也以每次任务执行的时间来衡量（例如，每次单击的秒数）。
换言之，当你在 Taco Tico 点午餐时，你收到订单的响应时间（R）是你在柜台前等待有人接受你的订单所花费的排队延迟时间（Q），再加上你在开始与订单管理员交谈后等待订单送达的处理时间（S）。队列延迟是指给定任务的响应时间与空载系统上同一任务的响应时间之差（不要忘记我们完美可扩展性假设）。
拐点
说到性能，你希望从一个系统中得到两点：
- 你可以获得的最佳响应时间：你不想等太久才能完成任务。
- 你可以获得的最佳吞吐量：你希望能够将尽可能多的负载塞进系统，以便尽可能多的人能够同时运行他们的任务。
不幸的是，两个目标是互相矛盾的。优化达到第一个目标需要最大程度地减少系统的负载；优化达到第二个目标需要将负载最大化。两者无法同时兼得。系统的最佳负载是在介于两者之间的某个位置的某种负载水平（即，在某个利用率值）。
负载达到最佳平衡的利用率值称为拐点，该点是吞吐量最大化且对响应时间的负面影响最小的点。（我正在就在这种情况下使用拐点一词是否合适进行持续的辩论。目前，我将继续使用它。有关详细信息，请参阅下面的注解。）从数学角度讲，拐点是响应时间除以利用率的最小值时的利用率值。拐点有一个很好的特性，穿过原点的直线与响应时间曲线的切点，此时的利用率值即拐点。在一个精心制作的 M/M/m 图上，你可以很好地用直尺定位拐点，如 Figure 5 所示。
M/M/m 拐点的另一个好特性是，只需要知道一个参数的值就可以计算它。这个参数是并行的、同质的、独立的处理通道数。处理通道是一种资源，需要共享单个队列。例如，收费站中的收费亭或 SMP（对称多处理器）计算机中的 CPU。
术语 M/M/m 中的斜体小写 m 是系统被建模的处理通道数。任意系统的 M/M/m 拐点值很难计算，但我已经在 table 5 中为你做了这项工作，table 5 显示了一些常见处理通道数的拐点值。（此时，你可能想知道 M/M/m 排队模型名称中的其他两个 M 代表什么。它们与传入请求的时间和处理时间的随机性的假设有关。有关信息请参阅 Kendall’s Notation，或参阅 Optimizing Oracle Performance[11] 获得更多有关详细信息。）
为什么拐点如此重要？对于随机处理请求的系统，允许资源负载持续超过临界值会导致响应时间和吞吐量随负载的微小变化而剧烈波动。因此，在随机请求到达的系统中，管理负载以使其不会超过拐点值是至关重要的。
拐点的相关性
拐点的概念到底是否真的如此重要？正如我告诉过你的，毕竟 M/M/m 模型假设了一个荒谬的乌托邦想法，即你所考虑的系统可以完美地扩展。我知道你在想什么：不可能。
M/M/m 给我们的知识是，即使你的系统能够完美地扩展，一旦你的平均负载超过 table 1 中的拐点值，你仍然会遇到大量的性能问题。你的系统不如 M/M/m 模型中的理论系统好。因此，与 table 1 中的值相比，系统拐点的利用率值将更小。（”值” 和 “拐点”是复数形式，因为你可以用一个模型来建模CPU，另一个模型来建模磁盘，另一个模型来建模I/O控制器，依此类推。）
回顾一下：
- 系统中的每种资源都有一个拐点。
- 每种资源的拐点小于或等于 table 1 中的拐点值。系统扩展性越不完善，拐点值就越小（越差）。
- 在随机请求到达的系统上，如果允许系统中任何资源的利用率持续超过该资源的临界值，那么性能就会出现问题。
- 因此，管理负载非常重要，这样资源利用率就不会超过拐点值。
