除了我们要评估的工作负载以外，系统是否还在处理其它工作。
我们是否有权使用会降低性能的工具（例如，系统是否处于生产中或在评估持续时间中是否为我们所专用？）.
我们能够模拟或观察真实工作负载的程度。
估计新程序需要的资源
对未编写的程序进行精确估计是不可能的。编码阶段发生的创作和重新设计是难以预见的，但下面的准则可以帮助您对需求有一个全面了解。作为一个起点，最小程序需要以下条件：
大约 50 毫秒的 CPU 时间，大部分是系统时间。
实内存
一个程序文本页面
大约 15 个页面（其中 2 个是暂存页面）用于工作（数据）段
对 libc.a 进行访问。通常这和所有其它程序共享，并当作操作系统基本成本的一部分。
大约 12 个页面调进的磁盘 I/O 操作（如果程序最近尚未编译、复制或使用）。否则什么都不需要。
除了上述一些方面，还有由设计所隐含要求的基本成本容差（给出的单元仅作示例用）：
CPU 时间
不包含高级迭代或昂贵子例程调用的普通程序的 CPU 消耗小得几乎不可测量。
如果提到的程序包含计算复杂的算法，则开发一个原型，对算法进行评估。
如果提到的程序使用计算复杂的库子例程，如 X 或 Motif 构造或 printf() 子例程，则用其它小程序对它们的 CPU 消耗进行评估。
实内存
每个程序文本页面允许大约 350 行代码，其中每行大约 12 字节。不要忘了编码风格与编译器选项可在任一方面产生一两种因素的差异。该容差是针对与您典型情况相关的页面的。如果您的设计在可执行程序的结束处安插有执行次数很少的子例程，则那些页面通常不消耗实内存。
引用共享库而不是 libc.a 会增加内存需求，仅从这个意义上来说，那些库并不与其它程序或正在估计程序的实例共享。为量度这些库的大小，请编写一个长期运行的引用那些库的小程序，并对进程使用 svmon -P 命令。
估计在设计中所确定的数据结构所需存储量大小。集中到最靠近的页面。
在短时间的运行中，每一个磁盘 I/O 操作使用一个内存页面。假设页面必须已是可用的。不要假设程序会等待另一个程序的页面释放。
磁盘 I/O
对于顺序 I/O，每读或写 4096 字节导致一个 I/O 操作，除非文件最近刚被访问过并且一些页面仍留在内存中。
对于随机 I/O，每一次对不同的 4096 字节页面的访问，无论大小，都会导致一个 I/O 操作，除非文件最近刚被访问过并且一些页面仍留在内存中。
每一次对大文件进行 4 KB 页面的顺序读写会占用大约 100 个单元。每一次进行 4 KB 页面的随机读写会占用大约 300 个单元。记住实际文件不一定顺序存储在磁盘上，尽管程序对它们进行顺序写和读。因此，与顺序存取成本相比，实际磁盘存取的典型 CPU 成本与随机存取成本更接近。
通信 I/O
如果磁盘 I/O 实际上是对网络文件系统（NFS）远程安装的文件系统的，则磁盘 I/O 在服务器上执行，但客户机会承担更高的 CPU 和内存要求。
任何一种 RPC 对 CPU 负载都有非常大的贡献。设计中提出的 RPC 应该预先进行最小化、批处理、原型化和评估。
每一次进行 4 KB 页面的顺序 NFS 读或写会占用客户机大约 600 个单元。每一次进行 4 KB 页面的随机 NFS 读或写会占用客户机大约 1000 个单元。
Web 浏览和 Web 服务暗示有大量的网络 I/O，同时 TCP 连接的打开和关闭非常频繁。
变换程序级别估计为工作负载估计
估计高峰和典型资源需求的最好方法是使用排队模型，如 BEST/1。您可以使用静态模型，但有冒高估或低估高峰资源的危险。在任一情况下，从资源需求的观点出发，您都需要理解工作负载中的多个程序是如何交互的。
如果您正在构建一个静态模型，请使用时间间隔，这是对大多数频繁运行或苛求的程序（通常两者是相同的）而言可接受性最差的响应时间。决定在每个时间间隔中通常运行哪些程序，这要基于您所规划的用户数、他们的思考次数、击键输入速率以及预期的混合操作。
使用以下准则：
CPU 时间
在时间间隔中运行的所用程序的 CPU 需求总和。包括程序正要执行的磁盘和通信 I/O 的 CPU 需求。
如果在时间间隔中这个数字大于可用 CPU 时间的 75%，则应考虑减少用户数或增加 CPU。
实内存
操作系统内存需求随物理内存大小而变化。操作系统本身使用 6 到 8 MB。单机系统中该数字更小。后一个数字是对 LAN 连接以及使用 TCP/IP 和 NFS 的系统而言的。
在时间间隔中运行的程序所有实例的工作段需求总和，包括为程序数据结构所估计的空间。
即将运行的每个不同程序文本段的内存需求（一个程序文本副本为该程序所有实例服务）的总和。记住来自非共享库的任何（且仅仅）子例程将成为可执行程序的一部分，但这些库本身并不在内存中。
每一个由工作负载中任何程序使用的共享库所消耗的空间大小总和。再次强调，一个副本可供所有实例使用。
为了提供足够的空间用作某种文件高速缓存和自由列表，您的内存规划总和不应超过要使用的机器大小的 80%。
磁盘 I/O
每个程序的每个实例所暗示的 I/O 总数。分别计算小文件（或随机读写的大文件）与完全顺序读或写的大文件（大于 32 KB）的 I/O 总数。
除去那些您认为可以从内存中获得的 I/O。前一个时间间隔的任何读或写记录在当前时间间隔中很可能仍然可用。此外，检查提出的机器的大小并与机器工作负载的总 RAM 需求对比。操作系统需求与工作负载需求之外的所有剩余空间可能包含最近读或写的文件页面。如果您的应用程序设计如上面所述，那么很有可能您会重新使用最近访问过的数据，您可以针对高速缓存的效果计算容差。记住重新使用是在页面级别上，而不是记录级别上。如果重新使用一条给定记录的可能性很低，但每个页面又有大量记录，则在任何给定时间间隔中需要的一些记录可能会像最近使用过的其它记录一样落在同一页面中。
把净 I/O 需求（每张磁盘每秒钟的磁盘 I/O）与当前磁盘驱动器的近似容量相比较。如果随机或顺序需求超过要保存应用程序数据的相应的磁盘总容量的 75%，那么就有必要在应用程序运行时进行调谐（并且可能是扩展）。
通信 I/O
计算工作负载的带宽消耗。如果 LAN 上所有节点的总带宽消耗大于额定带宽的 70%（以太网中的 50%），您可能想使用带宽更高的网络。
对要加在服务器上的额外负载的 CPU、内存和 I/O 需求进行类似分析。
注:
记住只有当不可能进行综合评估时，这些准则才有用。任何可用来代替某个准则的应用程序特定的评估都会显著提高估计的精确性。
文章来源于领测软件测试网 https://www.ltesting.net/
