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

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

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

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

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

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

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

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

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

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

　　各种特定类型的用户 ? 计算机交互作用在大部分时间会经历的佳响应时间，以及对大部分时间的定义。响应时间从用户执行“运行”这个操作的时间直到用户从计算机接收到足够反馈以继续执行任务来衡量。这是用户的主观等待时间。它不是从一个子例程的入口到第一个写语句的时间。

　　如果用户对响应时间不感兴趣，而仅仅对结果感兴趣，您可以询问“当前独立执行时间估计值的十倍”是否可以接受。如果回答“是”，您可以继续讨论吞吐量。否则，您可以在用户十分注意的情况下继续讨论响应时间。

　　低程度可接受剩余时间的响应时间。较长的响应时间会使用户认为系统当机。您还需要指定剩余时间，例如，的高峰时刻，百分之一的交互作用。在的某特定时间减少响应时间很难办到，或者代价更高。

　　需要的典型吞吐量和将发生的次数。这并不是临时注意事项。例如，对一个程序的需求可能是每天运行两次：上午 10：00 和下午 3：15.如果这是一个运行 15 分钟，并且计划运行于多用户系统的有 CPU 限制的程序，则需要某种协商以便依次运行。

　　大吞吐量周期的大小和计时。

　　综合预期请求及其如何随时间变化。

　　多用户应用程序中每台机器的用户数及总用户数。此描述应包括这些用户登录和注销的次数，以及假设的击键速率、完成的请求和思考次数。您可能想弄清楚思考次数是否随前后请求而系统地变化。

　　用户所做的关于工作负载要在其上运行的机器的任何假设。如果用户头脑中存在一台具体的机器，那么确保您早了解它。同样，如果用户所采用的是特殊类型、大小、成本、位置、互联或任何其它变量，而这些变量将限制您满足前述需求的能力，那么假设也变为需求的一部分。满意程度可能不会在程序开发、测试或首次安装的系统上进行评估。

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