性能测试基础知识－性能的规划与实现

性能的规划与实现
    一个不能按意愿执行的程序是没有用处的。每个程序都必须满足某组用户（有时会是一组很大且需求各不相同的用户）的需求。如果程序的性能确实不能满足那些用户中很大一部分用户的需求，则不会使用这个程序。一个不被使用的程序是不能实现预期功能的。

    这种情况对经许可的软件包和用户编写的应用程序是确实存在的，尽管大多数软件包开发者意识到低性能的影响，并尽力提高程序的运行速度。不幸的是，他们不能预测程序要经历的所有环境和用途。让程序具有可接受性能的最终职责就落在了那些选择或编写、规划以及安装软件包的人身上。

    本章描述程序员或系统管理员可以确保新编写或购买的程序具有可接受性能的步骤。（当程序员这个词单独出现时，它包含系统管理员和任何对程序的最终成功负责的人。）

    为使程序达到可接受的性能，在工程开始时就要确定和量化可接受性，并且决不能忽视达到目标所需的方法和资源。尽管听起来这是基本方法，但一些编程工程却有意抵制它。他们采用一种清楚地描述为设计、编码、调试、可能是编写文档，有时间的话再确定其性能的策略。

    为使程序运行时不仅在逻辑上，而且在时间上都是可预知的，唯一办法就是在软件规划和开发过程中对性能注意事项进行整体考虑。由于安装者较之开发者有较少的自由，所以在现有软件安装时提前规划也许就更关键了。

    尽管对一个小程序来说，这个过程的细节可能看起来很繁重，但不要忘了我们还有第二个“记事本”。我们不仅必须保证新程序具有令人满意的性能，还须确保该程序对现有系统的补充部分不会降低运行于该系统的其它程序的性能。

确定工作负载的组成部分
无论程序是新编写的还是购买的、大程序还是小程序，开发者、安装者和预期用户都对程序的使用有所假设，比如：

谁使用该程序
程序在何种环境下运行
这些环境出现的频度，以及在某年某月某日某时会出现多少次
在这些环境下是否还需使用其它现有程序
程序运行于何种系统
有多少数据将要从何处进行处理
由程序或为程序创建的数据是否会在其它方面用到

    除非这些想法是作为设计过程的一部分提出的，否则很可能模糊不清，并且程序员将几乎无疑会有与预期用户不同的假设。甚至在程序员同时也是用户这样明显很普通的情况中，让假设无关会使以任何严格方式进行设计与假设的比较成为不可能。更糟的是，在对正进行的工作没有完全理解的情况下是不可能确定性能需求的。

编写性能需求文档
    在确定和量化性能需求时，确定某一特殊要求背后的推理是很重要的。这是规划过程总能力的一部分。用户可能会将其需求声明基于与程序员的假设不匹配的程序逻辑的假设。性能需求集至少应记录下面几点：

    各种特定类型的用户 — 计算机交互作用在大部分时间会经历的最佳响应时间，以及对大部分时间的定义。响应时间从用户执行“运行”这个操作的时间直到用户从计算机接收到足够反馈以继续执行任务来衡量。这是用户的主观等待时间。它不是从一个子例程的入口到第一个写语句的时间。
如果用户对响应时间不感兴趣，而仅仅对结果感兴趣，您可以询问“当前独立执行时间估计值的十倍”是否可以接受。如果回答“是”，您就可以继续讨论吞吐量。否则，您可以在用户十分注意的情况下继续讨论响应时间。

最低程度可接受剩余时间的响应时间。较长的响应时间会使用户认为系统当机。您还需要指定剩余时间，例如，一天的高峰时刻，百分之一的交互作用。在一天的某特定时间减少响应时间很难办到，或者代价更高。 
需要的典型吞吐量和将发生的次数。这并不是临时注意事项。例如，对一个程序的需求可能是每天运行两次：上午 10:00 和下午 3:15。如果这是一个运行 15 分钟，并且计划运行于多用户系统的有 CPU 限制的程序，则需要某种协商以便依次运行。
最大吞吐量周期的大小和计时。
综合预期请求及其如何随时间变化。
多用户应用程序中每台机器的用户数及总用户数。此描述应包括这些用户登录和注销的次数，以及假设的击键速率、完成的请求和思考次数。您可能想弄清楚思考次数是否随前后请求而系统地变化。
用户所做的关于工作负载要在其上运行的机器的任何假设。如果用户头脑中存在一台具体的机器，那么确保您早就了解它。同样，如果用户所采用的是特殊类型、大小、成本、位置、互联或任何其它变量，而这些变量将限制您满足前述需求的能力，那么假设也变为需求的一部分。满意程度可能不会在程序开发、测试或首次安装的系统上进行评估。

估计工作负载的资源需求
除非您正在购买配有详细资源需求文档的软件包，否则资源估计可能是性能规划过程中最困难的任务。造成困难有如下几个原因：

执行任何任务都有几种方法。您可以编写 C（或其它高级语言）程序、shell 脚本、perl 脚本、awk 脚本、sed 脚本、AIXwindows 对话等等。从性能观点看，一些看来特别适合算法和程序员生产力的技术非常昂贵。
有一条准则很有用，即，抽象级别越高，就越要谨慎，以确保某个系统不会承受令人惊讶的性能。请仔细考虑由一些明显无害的构造所暗示的数据量大小和迭代数量。

单个过程的精确成本是很难确定的。困难之处不仅仅是技术上的；还有哲学上的。如果多用户运行的给定程序的多个实例正在共享程序文本页面，则哪一个进程应该负责那些内存页面呢？操作系统将最近用过的文件页面保留在内存中，以便为重新访问该数据的程序提供高速缓存的效果。重新访问数据的程序应该对用来保留数据的空间负责吗？某些评估的粒度，比如系统时钟，可以在用于同一程序连续实例的 CPU 时间上产生变化。
有两种方法来处理资源报告的模糊性和可变性。第一种是忽略模糊性，持续消除可变性的来源，直到评估变得可一致性接受。第二种方法是尝试让评估尽可能真实，并从统计上描述结果。注意后者产生与生产环境有某种相关性的结果。

系统很少专门运行单个程序的单个实例。存在几乎一直处于运行的守护程序、频繁的通信活动和通常来自多个用户的工作负载。这些活动很少线性增加。例如，增加给定程序的实例个数几乎没有增加使用的新程序文本页面数，因为大部分程序已存在于内存中。但是，附加的进程可能导致对处理器高速缓存的额外争用，所以，不仅其它进程不得不和新进程共享处理器时间，而且所有进程都会经历执行每条指令需要更多周期的情况。这实际上使得处理器速度减慢，结果导致更频繁的高速缓存未命中。
为使您的估计与具体情况所允许的一样真实，请使用以下准则：

如果程序存在，对最类似您自己需求的现有安装进行评估。最好的方法是使用容量规划工具，如 BEST/1。
如果没有合适的安装可用，则进行试安装并对综合工作负载进行评估。
如果生成与需求相匹配的综合工作负载是不实际的，则评估个体的交互作用并将结果用作仿真输入。
如果程序还不存在，查找使用同种语言和通用结构的同等程序并对其进行评估。再次强调，语言越抽象，在确定可比性时就越需谨慎。
如果同等程序不存在，则用规划的语言开发一个主要算法的原型，对这个原型进行评估并对工作负载建模。
只有当任何类型的评估都是不可能或不可行的，您才应作一个有根据的猜测。如果在规划阶段有必要对资源需求进行猜测，则在其开发阶段尽早对实际程序进行评估是很关键的。
牢记独立软件供应商（ISV）对他们的应用程序常常有可缩放的准则。

在估计资源时，我们主要对四个方面感兴趣（无特殊顺序）：

CPU 时间
工作负载的处理器成本
磁盘访问
工作负载产生的磁盘读写速率
LAN 流量
工作负载生成的信息包数目和交换的数据字节数
实内存
工作负载所需 RAM 的大小
以下各节讨论了在各种情况下如何确定这些值。

评估工作负载资源
如果实际程序、可比程序或原型对评估都是可用的，则技术方法的选择依赖以下几点：