通信 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/
