本节书摘来自异步社区《应用程序性能测试的艺术（第2版）》一书中的第1章，第1.1节从终端用户角度看性能，作者【新西兰】Ian Molyneaux（莫得尼克斯），更多章节内容可以访问云栖社区“异步社区”公众号查看。

第1章 为什么要做性能测试
应用程序性能测试的艺术（第2版）
快过极速子弹！

——动作漫画，超人
欢迎开启性能测试之旅！在开始探索性能测试的基础知识之前，我想在第1章里花点时间探讨一下什么是我们认为的好性能、什么是差性能以及为什么性能测试是整个软件生命周期（Software Development Lifecycle，SDLC）当中至关重要的一个环节。性能糟糕的应用通常无法为企业带来期望的收益。这些应用纯粹是耗费时间和资金，无法获得客户的认可，因此并不能有效转化为企业资产。如果一个应用/软件无法保证高性能、高可用地提供预期服务，那么无论是什么原因，都会给参与项目的团队成员，包括架构、设计、编码、测试（如果有的话）带来负面影响。

对比在业界发展相当成熟且广为人知的功能测试或者运行验收测试（Operational Acceptance Testing，OAT），性能测试未能引起足够的重视。时至今日，很多公司依然忽视性能测试的重要性，常常发布一些性能状况尚不明朗的应用，而这些应用通常上线不久就会因为性能或者扩展性问题给公司带来困扰。尽管很多性能咨询专家（包括我在内）一直致力于性能测试的推广，也有不少业界高曝光度的系统因为性能问题而饱受诟病，但大家对于性能测试的观念却依然没有明显改观。

1.1 从终端用户角度看性能
什么样的应用可以认为是运行性能很好呢？根据我和客户、性能团队多年共事的经验，性能其实是一种感受。当一个终端用户使用一个性能很好的应用时，他通常感受不到由于延迟带来的不畅或困扰。性能说到底是一个很主观的东西，是一种因人而异的感受。一个性能很好的应用不会让用户在完成一些操作时分散注意力，就好比当你登录某个网站时，一个性能很好的网站不会出现一个空白页让你等很久。

这听起来好像很简单，或许你对于什么叫好的性能也有自己的见解。但是无论你如何定义它，很多应用甚至连最基本的性能期望都不能满足（比如当系统处在负载高峰的时候）。当然，当我谈到应用性能状况的时候，其实是在指向应用各个组件的综合性能。毕竟应用的各个组件共同决定了应用性能。宏观上来看，一个应用的性能可以从客户端、应用软件和承载应用的硬件基础这几个方面来定义。硬件基础又包括运行软件的服务器和用于应用组件之间相互通信的网络基础设施。现在，随着分布式应用架构的广泛使用，应用所依赖的第三方服务也制约着应用的整体性能。说到底，上面提到的任何一个方面出了问题，应用的整体性能都会受到影响。也许你会认为，我们只要通过观察应用各个组件在负载或者压力模式下的表现，发现问题就解决问题，兵来将挡、水来土掩就一定能保证应用的整体性能。而事实却表明使用这种方式往往是“杯水车薪，悔之晚矣”，你所做的只不过是在头痛医头、脚痛医脚，对于造成性能问题的根本原因已经很难定位。

1.1.1 性能度量
性能应该如何度量呢？在前面，我们讨论了终端用户感受，但是要精确地进行性能度量，就必须引入一些关键性能指标（Key Performance Indicator，KPI）。这些指标属于非功能需求的一部分，关于非功能需求我们会在第3章详细讨论。我们暂时将指标分为两类：面向服务的和面向效率的。

面向服务的指标包括可用性和响应时间，这两个指标用来衡量一个应用是否能够很好地为终端用户提供服务。面向效率的指标包括吞吐率和资源利用率，它们用来衡量一个应用是否能够有效地利用系统资源。我们可以进一步为这些指标做以下定义。

可用性
通常采用应用对于终端用户的可用时长来衡量。高可用至关重要，因为很多应用如果发生不可用的情形，哪怕是很短的时间都会给业务带来不可估量的损失。换成性能术语可以这样描述：当一个应用无法响应或者可以响应但是响应时间已经增长到用户无法接受的程度，以至于终端用户完全不能正常使用该应用时，我们就认为这个应用此时不可用。

响应时间
应用响应一个用户请求所消耗的时间。在性能测试里，响应时间一般都指系统响应时间，即从用户发起请求到应用响应完全到达用户客户端所消耗的时间。响应可以是同步的（阻塞式）也可以是异步的，一个异步响应不会在返回结果前阻塞用户与应用的交互。关于这一点，我们会在后面的几个章节做更多讨论。

吞吐率
某种面向应用的事件的发生速率。比如在单位时间内一个网页的点击次数。

资源利用率
对某种资源理论容量的使用百分比。比如一个应用消耗了多少的网络带宽，又比如当有1000个并发用户的时候，一个Web服务器集群所消耗的内存。

把上述这些指标结合起来，我们就可以对应用的性能及其对资源的消耗有一个比较准确的认识。

1.1.2 性能标准
千万别以为我会在这一节给出一个普适的行业性能标准，这世上并不存在一个权威指南告诉我们什么是好的性能、什么是差的性能。总有一些人试图为性能制定一些量化的标准，特别是针对基于浏览器的应用。你也许听说过一个叫“最小页面刷新时间”的东西。我记得最初有人将他定义在20秒，没过多久就变成了8秒，而现在这个时间是2秒或者更快。当然，对于用户（业务）来说，***是“瞬间响应”（就像老鹰乐队唱的那样：“生活就像快车道，所有一切刹那至”），然而这种一致性能的想法很有可能会一直是一个幻想。

20世纪80年代后期，马丁等人试图绘制终端用户生产效率和响应时间之间的关系图表。这些初始研究大多是基于古老的绿屏文字类应用（比如Turbo C）做的，但是研究的结论时至今日还是非常有参考意义的。

超过15秒
这么长的响应时间排除了会话式交互的可能性。也许针对某些类型的应用，有些终端用户愿意等上15秒才看到一个简单查询的反馈。但对于类似呼叫中心的接线员，或者那些期货交易员来说，15秒的响应时间是完全无法接受的。如果应用的交互中会出现这么长时间的延迟，我们应该考虑将系统设计成异步的，允许用户提交查询后可以切换到其他界面操作，稍后再来查看之前查询的返回结果。

超过4秒
超过4秒的延迟对于会话式的交互而言会显得太长，用户不得不将之前获得的信息暂存在短期记忆里（用户的大脑，而非电脑！）。这样的延迟通常会不利于用户解决问题，也会让数据录入变得让人苦恼。然而，在用户提交一个较为复杂的事务时，4～15秒的延迟时间还是可以接受的。

2～4秒
超过2秒的延迟不利于进行需要注意力高度集中的连续性操作。当用户全神贯注地在完成手头的一个任务时，2～4秒的延迟时间对他而言就显得相当漫长了。当然，在完成一些阶段性的简单操作的时候，这类延时还是可以接受的。比如对消费者来说，在他们输入地址和信用卡以后等上2～4秒钟或许是可以接受的，但绝不是在开始比较商品属性的早期行为中。

小于2秒
如果用户需要在多个响应中记住若干的信息，那么响应时间必须足够短。用户要记的信息越详细，我们越需要把响应时间控制在2秒以下。因此，对于一些复杂的操作，比如浏览不同维度的多个商品，2秒是一个非常关键的响应时间上限。

小于1秒
一些思维密集型的工作（比如写作），会要求应用具备非常短的响应时间，特别是如果这个应用有着非常丰富图形化的界面，那么这个要求会更高。因为只有这样才能让用户长时间地集中注意力。设想一个艺术家在界面上拖动一幅图像到另一个位置，他需要得到立即响应才不至于打断他的创造性思路。

小于0.1秒
当我们敲击键盘（看到字母在屏幕上显示）或者用光标点击屏幕上的一个物体时，我们期望的响应是实时的：动作发生后0.1秒内响应。很多电脑游戏都要求极速的交互响应。

回顾上面这几个响应时间，最关键的一个界限似乎是2秒。超过2秒的响应时间一定会对用户的生产效率产生影响，所以如今8秒的网页刷新时间标准就显得非常不理想了。

1.1.3 万维网与电子商务
如今大家对应用程序高速运行的要求越来越高（***都能装上“曲速引擎”），万维网（World Wide Web）的爆炸性发展在这个过程中扮演的角色不容忽视。很多（也许应该说所有？）电子商务公司现如今都在互联网这个能够想到的最激烈的竞争环境下争夺自己的利益地盘。如果你的网站性能没让用户满意，他的下一次点击就会是“你的竞争对手.com”了。

电子商务应用面对需求骤升的高峰时，往往力不从心。这一点，很多大型网上零售商店深有体会。