执行任何任务都有几种方法。您可以编写 C(或其它高级语言)程序、shell 脚本、perl 脚本、awk 脚本、sed 脚本、AIXwindows 对话等等。从性能观点看，一些看来特别适合算法和程序员生产力的技术非常昂贵。

　　有一条准则很有用，即，抽象级别越高，越要谨慎，以确保某个系统不会承受令人惊讶的性能。请仔细考虑由一些明显无害的构造所暗示的数据量大小和迭代数量。

　　单个过程的精确成本是很难确定的。困难之处不仅仅是技术上的;还有哲学上的。如果多用户运行的给定程序的多个实例正在共享程序文本页面，则哪一个进程应该负责那些内存页面呢?操作系统将近用过的文件页面保留在内存中，以便为重新访问该数据的程序提供高速缓存的效果。重新访问数据的程序应该对用来保留数据的空间负责吗?某些评估的粒度，比如系统时钟，可以在用于同一程序连续实例的 CPU 时间上产生变化。

　　有两种方法来处理资源报告的模糊性和可变性。第一种是忽略模糊性，持续消除可变性的来源，直到评估变得可一致性接受。第二种方法是尝试让评估尽可能真实，并从统计上描述结果。注意后者产生与生产环境有某种相关性的结果。

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

　　为使您的估计与具体情况所允许的一样真实，请使用以下准则：

　　如果程序存在，对类似您自己需求的现有安装进行评估。好的方法是使用容量规划工具，如 BEST/1.如果没有合适的安装可用，则进行试安装并对综合工作负载进行评估。

　　如果生成与需求相匹配的综合工作负载是不实际的，则评估个体的交互作用并将结果用作仿真输入。

　　如果程序还不存在，查找使用同种语言和通用结构的同等程序并对其进行评估。再次强调，语言越抽象，在确定可比性时越需谨慎。

　　如果同等程序不存在，则用规划的语言开发一个主要算法的原型，对这个原型进行评估并对工作负载建模。

　　只有当任何类型的评估都是不可能或不可行的，您才应作一个有根据的猜测。如果在规划阶段有必要对资源需求进行猜测，则在其开发阶段尽早对实际程序进行评估是很关键的。

　　牢记独立软件供应商(ISV)对他们的应用程序常常有可缩放的准则。

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

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

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

　　除了我们要评估的工作负载以外，系统是否还在处理其它工作。