计算机系统性能的重要挑战

本文是翻译,版权归原作者所有



计算机系统性能的重要挑战,对你而言,你的系统要有足够能力去处理你的需求。听起来非常简单,但是帮助别人应对这个挑战,一直是我整个职业生涯的重点。我为此辛劳了 26 年,终日碌碌,没有尽头。

容量和工作量

我们的挑战就是一台计算机的容量(capacity)及其工作量(workload)之间的关系。我把容量看做是一个空盒子,用来代表一台机器在一段时间内能够完成工作的能力。而工作量则是你的计算机以程序运行的方式、在一段时间内实际执行的工作。工作量是就是能够装填容量盒子的容量。

计算机的容量(capacity)及其工作量(workload)

容量是可控的,对吗?

当工作量几乎要填满盒子时,你该做什么?大部分人的本能反应会是,我们需要更大的盒子。系统慢了?增加容量就行。说来轻巧,更何况「众所周知」,计算机每年都变得更快、更便宜。我们称之为 KIWI 反应:kill it with iron。

KIWI……为什么不是呢?

或许我们觉得 KIWI 大行其道,不过,它太昂贵,且不一定好使。或许你刚好没有升级新机器的预算。升级成本不仅包括硬件本身:还有时间和金钱,配置、测试、以及应用程序的迁移。你的软件或许需要更高的成本,才能运行在更快的硬件上。如果你的系统已经是最庞大、最快的了,该怎么办呢?

升级到一台更强大的电脑,不总是让你的程序运行得更快,这或许有些奇怪。还有一类性能问题,增加容量也无法解决(是的,有可能预测到问题发生的时间)。KIWI 不总是一个可行的方案。

那么,你还能做什么?

性能不总是关乎容量。对于工作量而言,很多人忽视了它们,但是,也存在着解决方案。如果不用损害系统的价值,就能让工作量更少,会怎样呢?

让计算机输出你需要的、所有有用的结果,而无需做太多工作,通常是可能的。

让容量盒子变得更大,或许能够让系统运行得更快。但是,通过从现有盒子里砍掉耗资源的工作量,也可能让其更快速地运行。如果你只是移除无用的东东,那么没有人受到影响,你将赢得胜利。

那么,该如何做好这一块呢?

工作量

「工作量(workload)」由两个词语合成。分开考虑这两个词语,会有新发现。

「工作量(workload)」由两个词语合成

「work」是指系统根据已有程序执行后所完成的工作,主要决定于程序编写的方式。很多程序员本不应该让系统做那么多工作。另一方面,你的「load」——人们请求的程序执行的数量——主要决定于你的用户。用户也能浪费系统容量;比如,运行一份没人会看的报表。

「work」和「load」都是变量,有了该技巧,你就能管控优势。你可以优化程序里的代码(减少 work),或优化业务流程(减少 load)。我喜欢工作量优化,因为它们常常节省资金和工作,比增加容量好多了。工作量优化貌似具有魔力。

剖析性能

有个简单的等式,解释了程序消耗时间的原因:

r = cl response time = call count × call latency

把一次调用(a call)看成一条计算机指令。那么,调用总数(call count)就是程序运行时、系统执行的指令总数,而调用延迟(call latency)就是每条指令所需时间。你等待结果的时间——你的响应时间——就是调用总数和调用延迟的乘积。

细则:实际情况要比上面等式复杂,但是没有复杂多少。大多数响应时间由很多不同种类的调用组成,所有调用有着不同的延迟(可以在程序执行总览里看到),因此实际等式就接近于 r = c1l1 + c2l2 + … + cnln。但是,本文使用 r=cl 示意。

调用总数依赖于两个因素:代码编写的方式,和人们运行代码的频率。

调用延迟受两种延迟的影响:队列延迟和一致性延迟。

秘密

r = cl 看起来像个线性等式,但是由于队列和一致性延迟,l 的值随着 c 的增长而增长。这使得响应时间的表现不像是线性,而是曲线。

r = cl 是个曲线

由于我们的大脑倾向于把世界看做是线性的,当你只增加一点点的新工作量时,没人愿意期望每个人的响应时间增加 7 倍,但是这种现象常常和性能连在一起……不限于计算机性能。银行、高速公路、餐厅、娱乐场所,和杂货店购物机器人的模式都一样。

响应时间对于你的调用总数相当敏感,因此,高性能的秘密就是保持调用总数少一些。这条准则可能是曾经提出的、最好最著名的性能优化建议的基础:

程序优化第一准则:不要优化。 程序优化第二法则(仅对专家适用)还是不要优化。 — [Michael A. Jackson](https://en.wikipedia.org/wiki/Michael_A._Jackson)【注1】

问题

保持调用总数少,真的、真的重要。这提高了成为一家信息服务提供商的门槛,因为应用程序用户很容易就能让调用总数增加。方式有很多,他们可以运行更多程序、增加更多用户、增加新的功能或报表、或每天只是通过例行过程就能增加更多数据。

在同一台计算机上运行你的和其它的应用程序,会使得问题复杂化。如果所有这些应用程序的工作量峰值重叠了,会出现什么状况呢?这是应用程序服务提供商(ASP)软件即服务(SaaS)提供商云计算提供商必须要解决的问题。

解决方案

解决方案需要一个过程:

  1. 调用总数需要慎重对待。它们难以预测,因此你不得不经常测量它们、理解它们。雇佣能够理解它们的人,雇佣的人要明白如何测量并优化应用程序及其所运行系统的效率。

  2. 给同事修复低效率代码的时间。便宜的代码修复,可能是一次昂贵的硬件升级所带来益处的很多倍。如果你从软件提供商那里购买软件,就和他们协同工作,以确保他们能够简化交付给你们的代码。

  3. 学会说「不」的时机。不要增加低效的新功能(尤其是报表之类的新的、运行时间长的程序),会增加不必要的调用次数。如果用户创建的工作量已经接近系统能够处理的极限,那么,就该开始确定工作量的优先级,即在高峰期内,哪些工作量被允许运行或禁止运行。

  4. 如果你是一家信息服务提供商,就按照系统为客户完成的工作总量收费。开发和采购更有效程序的、经济方面的动机,会创造出奇迹。

注释

译文:计算机系统性能的重要挑战 》| 腊八粥