最低程度可接受剩余时间的响应时间。较长的响应时间会使用户认为系统当机。您还需要指定剩余时间，例如，一天的高峰时刻，百分之一的交互作用。在一天的某特定时间减少响应时间很难办到，或者代价更高。
需要的典型吞吐量和将发生的次数。这并不是临时注意事项。例如，对一个程序的需求可能是每天运行两次：上午 10:00 和下午 3:15。如果这是一个运行 15 分钟，并且计划运行于多用户系统的有 CPU 限制的程序，则需要某种协商以便依次运行。
最大吞吐量周期的大小和计时。
综合预期请求及其如何随时间变化。
多用户应用程序中每台机器的用户数及总用户数。此描述应包括这些用户登录和注销的次数，以及假设的击键速率、完成的请求和思考次数。您可能想弄清楚思考次数是否随前后请求而系统地变化。
用户所做的关于工作负载要在其上运行的机器的任何假设。如果用户头脑中存在一台具体的机器，那么确保您早就了解它。同样，如果用户所采用的是特殊类型、大小、成本、位置、互联或任何其它变量，而这些变量将限制您满足前述需求的能力，那么假设也变为需求的一部分。满意程度可能不会在程序开发、测试或首次安装的系统上进行评估。
估计工作负载的资源需求
除非您正在购买配有详细资源需求文档的软件包，否则资源估计可能是性能规划过程中最困难的任务。造成困难有如下几个原因：
执行任何任务都有几种方法。您可以编写 C（或其它高级语言）程序、shell 脚本、perl 脚本、awk 脚本、sed 脚本、AIXwindows 对话等等。从性能观点看，一些看来特别适合算法和程序员生产力的技术非常昂贵。
有一条准则很有用，即，抽象级别越高，就越要谨慎，以确保某个系统不会承受令人惊讶的性能。请仔细考虑由一些明显无害的构造所暗示的数据量大小和迭代数量。
单个过程的精确成本是很难确定的。困难之处不仅仅是技术上的；还有哲学上的。如果多用户运行的给定程序的多个实例正在共享程序文本页面，则哪一个进程应该负责那些内存页面呢？操作系统将最近用过的文件页面保留在内存中，以便为重新访问该数据的程序提供高速缓存的效果。重新访问数据的程序应该对用来保留数据的空间负责吗？某些评估的粒度，比如系统时钟，可以在用于同一程序连续实例的 CPU 时间上产生变化。
有两种方法来处理资源报告的模糊性和可变性。第一种是忽略模糊性，持续消除可变性的来源，直到评估变得可一致性接受。第二种方法是尝试让评估尽可能真实，并从统计上描述结果。注意后者产生与生产环境有某种相关性的结果。
系统很少专门运行单个程序的单个实例。存在几乎一直处于运行的守护程序、频繁的通信活动和通常来自多个用户的工作负载。这些活动很少线性增加。例如，增加给定程序的实例个数几乎没有增加使用的新程序文本页面数，因为大部分程序已存在于内存中。但是，附加的进程可能导致对处理器高速缓存的额外争用，所以，不仅其它进程不得不和新进程共享处理器时间，而且所有进程都会经历执行每条指令需要更多周期的情况。这实际上使得处理器速度减慢，结果导致更频繁的高速缓存未命中。
为使您的估计与具体情况所允许的一样真实，请使用以下准则：
如果程序存在，对最类似您自己需求的现有安装进行评估。最好的方法是使用容量规划工具，如 BEST/1。
如果没有合适的安装可用，则进行试安装并对综合工作负载进行评估。
如果生成与需求相匹配的综合工作负载是不实际的，则评估个体的交互作用并将结果用作仿真输入。
如果程序还不存在，查找使用同种语言和通用结构的同等程序并对其进行评估。再次强调，语言越抽象，在确定可比性时就越需谨慎。
如果同等程序不存在，则用规划的语言开发一个主要算法的原型，对这个原型进行评估并对工作负载建模。
只有当任何类型的评估都是不可能或不可行的，您才应作一个有根据的猜测。如果在规划阶段有必要对资源需求进行猜测，则在其开发阶段尽早对实际程序进行评估是很关键的。
牢记独立软件供应商（ISV）对他们的应用程序常常有可缩放的准则。
在估计资源时，我们主要对四个方面感兴趣（无特殊顺序）：
CPU 时间
工作负载的处理器成本
磁盘访问
工作负载产生的磁盘读写速率
LAN 流量
工作负载生成的信息包数目和交换的数据字节数
实内存
工作负载所需 RAM 的大小
以下各节讨论了在各种情况下如何确定这些值。
评估工作负载资源
如果实际程序、可比程序或原型对评估都是可用的，则技术方法的选择依赖以下几点：
除了我们要评估的工作负载以外，系统是否还在处理其它工作。
我们是否有权使用会降低性能的工具（例如，系统是否处于生产中或在评估持续时间中是否为我们所专用？）.
我们能够模拟或观察真实工作负载的程度。
文章来源于领测软件测试网 https://www.ltesting.net/
