应用程序性能测试的艺术（连载）第一章为什么要进行性能测试

                       第1章 为什么要进行性能测试

                        快过飞驰的子弹……

                                ---- 超人，《动作漫画》

本章提出了与这本书所有需要讨论主题相关的一些根本性问题。什么是性能测试？为什么执行性能测试至关重要？在本章中，我也

定义了什么时候是好的性能体验、什么时候是不好的性能体验，并且讨论了一些导致用户体验不佳的共同因素。

性能不佳的应用系统（例如：性能表现极差）通常无法实现企业预期利益，也就是说，企业为此（系统性能）花费了时间和金钱，

但是却在应用此系统的用户中失去了信誉，因此（这样的系统）不能被视为可靠的资产。

如果一个应用系统不能够为企业带来效益，那么他的存在就会岌岌可危，更不用说那些（与这个系统相关的）架构师、设计师、程

序员和测试员了（但愿有那么一些！）。

对于大多数的企业和那些成熟度较高的组织来说，单元测试、功能测试和系统测试是很容易理解的，然而性能测试却往往容易被忽

略。管理层并不能体会到性能测试的重要性，尽管这很奇怪，但确实是这样的。在过去的十年里，尽管许多像我这样的顾问为此做

了大量的宣传努力，但仍然收效甚微。

1.1    以最终用户的眼光看待性能

一个应用系统在什么样的情况下才会被认为拥有好的性能呢？我多年与客户和性能团队共事的经验表明“性能”是用户最终的一种

感受。一个性能优异的应用系统，在最终用户执行某项任务时，系统不会产生过度的延迟而引起用户的不满。关于性能这件事，正

所谓当局者迷，旁观者清 [1] 。

一个性能表现优异的应用系统，用户不会在登录系统的时候，迎来的却是一个空空如也的屏幕，并且用户可以流畅地完成他们预定

的任务，而不会走神 [2] 。当用户在一个购物网站上寻找和购买他们所需要的东西时，他们可以随心所欲地浏览购物网站，而不会

因为网站性能太差而感到很郁闷。

这听起来似乎并不难，对于究竟什么才算是好的性能，您应该也会有一套自己的看法。但无论您是怎么去定义他的，事实就是：许

多的应用系统都在不断地努力，以使自己的性能提高到可以被用户接受的程度。

当然，由于一个应用程序是由很多部分所构成的，所以我所说的应用系统，实际上指的是一个应用系统中所有的部分。从更高的层

面上看，我们可以将这些组成部分定义为应用程序软件，加上应用架构，后者包括了运行软件所需的服务器硬件，以及能够保证所

有应用组件间互相通讯的网络基础设施。一旦这些组成部分中的任何一个出现问题，整个系统的性能就将面临灾难。

您可能会简单地认为，为了保证应用系统拥有良好的性能，我们所要做的仅仅是观察应用系统的每个部分在负载压力下的运行状况

，并且解决所出现的问题而已。然而现实情况却并不是这样，因为这种做法往往来得“太少”和“太迟”了，因此只能是治标不治

本。以下的内容中将详细介绍如何进行性能评价。
1.1.1     性能度量

那么，我们应该如何去衡量系统的性能呢？我前面已经提到了最终用户的体验，但是为了更加准确地衡量性能，还有一些关键的指

标需要考虑。这些关键指标在本书的第 2 章中还会继续深入探讨；在这里，我们不妨将他们划分为两种类型：服务型和效率型。

针对服务型的指标有：可用性 和响应时间。 他们 所衡量的是应用系统为用户服务效果的好坏。效率型的指标有：吞吐量 和利用

率。 他们 所衡量的是应用系统在应用架构基础上对发挥效率的高低。我们可以简单地定义如下：

可用性

应用系统对于最终用户的可用时间 [3] 。可用性不好是很严重的问题，因为即便是一个小小的故障也会导致大量的商务上的花费。

在性能测试方面，这将意味着最终用户无法有效地使用该应用系统。

响应时间

应用系统对用户请求的给出响应的时间。对于性能测试而言，一个最常用的衡量指标就是系统响应时间，即从用户端发出请求到接

收到应用系统给出完整响应所经过的时间。

吞吐量

面向应用系统事件的发生频率。例如，在一段特定的时间内对某个 Web 页面点击的次数 [4] 。

利用率

占用系统资源的百分比。例如，当 1000 个用户同时在线时，在应用系统上消耗了多少网络带宽，以及在服务器上占用了多少内存

等。

我们将以上两种类型的指标结合起来考虑，就能够较为准确地衡量一个应用系统在的性能，以及他在应用架构基础上对系统能力造

成的影响。
1.1.2     性能标准

如果您指望我在这里给出一个关于性能好坏的行业标准，那我必须很遗憾地告诉您，没有这样的指导标准存在。不过，业内倒是有

许多非正式的标准，试图对系统的性能好坏做出评价，尤其是针对基于B/S 架构的应用系统。举例来说，您可能听说过“页面最小

刷新时间”这种说法； 我记得经过20 秒，迅速提高到8 秒。当然了，用户和企业都希望系统能够“即时响应”（用老鹰乐队的话

来说就是：“随时待命”），但这样的性能要求是很难达到的。

许多商业服务水平协议（ SLA ）涵盖基础设施的性能，而不是应用程序本身，他们往往只涉及具体的领域，如网络延迟或服务器可

用性等。

以下的内容列出了在 80 年代后期，（马丁， 1988 年）马丁研究如何使用响应时间来衡量用户的工作效率的主要成果。最初的研

究主要是基于绿屏软件 [5] 文本的应用，但这些结论现在仍然具有参考意义。

超过15 秒

出现这种情况，就基本排除了互动的可能性。对某些特定的应用系统，某些用户可以坐在一个终端前坐上超过15 秒的时间去等待一

个查询结果的返回。然而，对于一个繁忙的呼叫中心运营商或期货交易商来说，超过15 秒的延迟却是无法容忍的。如果真的发生了

延迟，系统就应该设计成可以让用户转向其他的操作，并且在后续的时间里继续请求响应。

超过4 秒

这样的延迟一般对于一个要求终端用户保存在短暂记忆里的会话来说太长了（是终端用户的记忆，不是计算机的内存！） 这样的延

迟将妨碍解决问题的活动和破坏数据的录入。然而，当一个交易完成之后，4 秒到15 秒的延迟是可以忍受的。

2 秒到 4 秒

超过2 秒钟的延迟可以被抑制这种需求的高度集中。 当用户专注地去完成一项手头的任务时，终端的一个2 秒到4 秒左右的延迟看

起来就似乎非常地长了。同样地，在一个无关紧要的任务结束后，2 秒到4 秒钟的延迟在一个无关紧要的，又是可以接受的。当一

个买家在输入了她的地址和信用卡号码后，让她等待2-4 秒的时间，她也许可以接受。然而如果是在早先的阶段，当她正在比较不

同产品的功能差异时，却又是不可容忍的。

低于 2 秒

当系统的用户需要记住几个响应信息时，此时的响应时间必须很短，如果要记住更为详细的信息，则要求就更高了，要求响应时间

不能超过 2 秒。因此，对于那些较为复杂的活动，例如通过不同的规格尺寸去浏览相机产品时， 2 秒钟是一个很重要的响应时间

限制。

亚秒

对于那些思想密集型的工作来说（比如写一本书），尤其是一个图形应用程序，响应时间要非常短，才能够保持用户的兴趣和吸引

他长时间的关注。当一位艺术家将一幅图片拖曳到另一个位置时，程序必须能够立即对他下一次的创意给出响应。

0.1 秒

在键盘上敲下一个按键，并在屏幕上出现相应的字符，或者用鼠标点击屏幕上的一个对象，这种响应必须几乎是瞬时的。很多电脑

游戏都会要求非常快的互动响应。

由此可见，关键的响应时间临界点是 2 秒。对于普通用户来说，响应时间超过 2 秒钟势必会对他们的使用造成一定的影响，因此

，我们若将页面刷新时间定义为 8 秒，对于互联网的应用来说，肯定是不够理想的。
1.1.3     互联网的影响

互联网应用的“爆炸式（ Big Bang ）”增长为程序的快速应用提供了一个很好的发展方式。当前，许多（或者说绝大多数？）的

企业发现，依靠互联网来增加他们的收益是一个能想到的相当不错的方法。但是如果最终用户认为您的 Web 站点性能不好，那么他

们的下一次点击很可能就会转到您的竞争对手的网站上去了。

另外，对于那些突发的需求高峰来说，用户界面的应用也是十分脆弱的；已经有相当多的知名零售公司发现了在每一年中的购物高

峰期出现性能问题。

总之一句话：互联网的发展对于应用系统带来了商机也带来的性能方面的挑战。

[1] 译者注：“这里的当局者指的是：系统的开发人员；旁观者指的是：最终用户”。

[2] 译者注：“这里说明，系统应该快速响应用户的请求”。

[3] 译者注：这里的“可用性”就是我们通常说的平均无故障时间。系统在不出现故障的情况下可以运行的最长时间。有的时候我

们也叫他系统的“可靠性”。

[4] 这里 Ian 举的例子指的就是我们在性能测试中通常说的一个指标“每秒钟点击数（ Hits/s ）”，单位时间向 web 服务器发

出的 HTTP 请求数（这里的请求包括 HTML 资源的请求和非 HTML 资源的请求）。 HTTP 请求包括以下类型：

1）   GET ：从服务器上发送给客户端指定的资源。

2）   PUT ：从客户端存储数据到一个指定的服务器资源。

3）   DELETE ：从服务器上删除指定的资源。

4）   POST ：发送客户端数据给服务器。

5）   HEAD ：对于指定的资源只发送 HTTP header 响应信息，即不传输主体数据。

[5] 译者注：绿屏软件是计算机早期的一种应用软件，主要是基于字符界面的应用，以下是一个典型的绿屏应用：