我的书签
添加书签
移除书签1.1 以最终用户的眼光看待性能
一个应用程序在什么样的情况下才会被认为拥有好的性能呢？
我多年与客户和性能团队共事的经验表明“性能”是用户的一种最终感受。一个性能优异的应用程序，在最终用户执行某项任务时，程序不会产生过度的延迟而引起用户的不满。关于性能这件事，正所谓当局者迷，旁观者清[1]。
一个性能表现优异的应用程序，用户不会在登录系统的时候，迎来的却是一个空空如也的屏幕，并且用户可以流畅地完成他们预定的任务，而不会走神（译。当用户在一个购物网站上寻找和购买他们所需要的东西时，他们可以随心所欲地浏览购物网站，而不会因为网站性能太差而感到很郁闷。
这听起来似乎并不难，对于究竟什么才算是好的性能，您应该也会有一套自己的看法。但无论您是怎么去定义它的，许多应用程序都在不断地改进，以使自己的性能提高到可以被用户接受的程度。
当然，由于一个应用程序是由很多部分所构成的，所以我所说的应用程序，实际上指的是一个应用程序中所有部分。从更高的层面上看，我们可以将这些组成部分定义为应用程序软件，加上应用架构，后者包括了运行软件所需的服务器硬件，以及能够保证所有应用组件间互相通信的网络基础设施。
当然一旦这些组成部分中的任何一个出现问题，整个系统的性能就将面临灾难。
您可能会简单地认为，为了保证应用程序拥有良好的性能，我们所要做的仅仅是观察应用程序的每个部分在负载压力下的运行状况，并且解决所出现的问题而已。然而现实情况却并不是这样，因为这种做法往往“太少”和“太迟”了，因此只能是治标不治本。以下的内容中将详细介绍如何进行性能评价。
1.1.1 性能度量
那么，我们应该如何去衡量系统的性能呢？我前面已经提到了最终用户的体验，但是为了更加准确地衡量性能，还有一些关键的指标需要考虑。这些关键指标在本书的第2章中还会继续深入探讨；在这里，我们不妨将它们划分为两种类型：服务型和效率型。服务型指标有：可用性和响应时间。它们所衡量的是应用程序为用户服务效果的好坏。效率型指标有：吞吐量和利用率。它们所衡量的是应用程序在应用架构基础上发挥效率的高低。我们可以简单地定义如下。
可用性
它是应用程序对于最终用户的可用时间[2]。可用性不好是很严重的问题，因为即便是一个小小的故障也会导致大量的商务上的花费。在性能测试方面，这将意味着最终用户无法有效地使用该应用程序。
响应时间
应用程序对用户请求给出响应的时间。对于性能测试而言，一个最常用的衡量指标就是系统响应时间，即从用户端发出请求到接收到应用程序给出完整响应所经过的时间。
吞吐量
面向应用程序事件的发生频率。例如，在一段特定的时间内对某个Web页面点击的次数[3]。
利用率
占用系统资源的百分比。例如，当1000个用户同时在线时，在应用程序上消耗了多少网络带宽，以及在服务器上占用了多少内存等。
我们将以上两种类型的指标结合起来考虑，就能够较为准确地衡量一个应用程序的性能，以及它在应用架构基础上对系统能力造成的影响。
[1]“这里的当局者指的是：系统的开发人员；旁观者指的是：最终用户”。
[2]这里的“可用性”就是我们通常说的平均无故障时间。系统在不出现故障的情况下可以运行的最长时间。有的时候我们也叫它作系统的“可靠性”。
[3]这里作者举的例子指的就是我们在性能测试中通常说的一个指标“每秒钟点击数（Hits/s）”，单位时间向Web服务器发出的HTTP请求数（这里的请求包括HTML资源的请求和非HTML资源的请求）。HTTP请求包括以下类型：1.GET：从服务器上发送给客户端指定的资源。2.PUT：从客户端存储数据到一个指定的服务器资源。3.DELETE：从服务器上删除指定的资源。4.POST：发送客户端数据给服务器。5.HEAD：对于指定的资源只发送HTTP header响应信息，即不传输主体数据。
