IO性能是服务器测试的重头戏。普遍认为，在实际应用中，数据的输入输出几乎是完全随机性的。如此类的应用包括电子邮件服务器、网站服务器、数据库和文件传输服务器。当然，在服务器复制和磁盘备份中，情况将会产生变化，会有更多的连续性读写操作发生。

　　通过对数据传输大小的分析得出，小于4KB的传输片段是很少见的，而在所有测试组件的运行中，大多数访问超出了这一限制。另外，随时随地使用的聚散列表算法和中断接合进程更进一步支持这一低限值。高限值则取决于应用。

　　我们采用业界认可的IOMeter 2004.07.30.win32.i386版本来完成磁盘子系统性能的测试并使用定制的Excel宏来完成数据分析。IOMeter是一款功能非常强大的IO测试软件，它包含了负载发生器（IOMeter称其为Worker），提供一系列标准测试组件以模仿实际应用，如WebServer（网站服务器）、FileServer（文件服务器）和在OLTP（OnLine Transaction Processing，在线交易处理）服务器。这些测试组件产生不同大小的输入输出请求和读/写分布，以模仿实际应用中的行为。

　　IOMeter还允许使用者自行设定输入输出参数，如大小、队列深度和读写分布等，使系统按照用户的特定意愿进行工作。输入输出大小的设定可从1字节按对数方式增加到1兆字节以上。同样，队列深度和读/写分布可以按用户指定的参数变化。当一系列参数指标被确定后，使用者必须明确所用的测试参数具有相关性。比如，小块连续数据模式在实际应用中并不存在，因此其反映的信息对实际情况而言是模糊的。

　　我们测试的服务器通过LSI53C1020A Ultra 320 SCSI控制器将两个ST373207LC硬盘配置为一个RAID 1阵列，最后得到的虚拟硬盘分为2个分区，第一个分区为20GB，剩下的全部为第二个分区，我们对第一个分区进行了IOMeter测试。

　　测试运行结合了标准OLTP、文件服务器和网站服务器。此外，针对不同的应用，采用了不同输入输出范围内的连续读写方式。对于数据输入/输出大小的设定，服务器应用采用4KB到64KB范围，而连续性传输应用则采用64KB到1MB范围。

　　在I/O范围内的每个点上都建立一个性能图表是很笨拙的，因此对OLTP应用，我们将以8KB作为测试点。而通过使用不同的IOMeter设定值来呈现文件服务器（选择范围为512Bytes到64KB）和网站服务器（选择512Bytes到512KB作为I/O范围）的相应负载，文件服务器和网站服务器的脚本都按照于StorageReview.com的脚本来进行，StorageReview.com通过对各种文件服务器和网站服务器的实际运行进行统计分析制定了业界广泛使用的测试脚本，我们认为这些的脚本是很正确的。连续性操作的设值为64KB，因为这是Windows NT系列系统所使用的限定数值。

最后，我们实际测试使用的IOMeter策略如下：

Defualt：
IOMeter自身带有的一个脚本，测试读取尺寸为2KB，读取占全部操作的67%，随机率为100%。

Max IO：
测试读取尺寸为512Bytes，100%读取操作，随机率为0%，即为100%连续读取，用于检测磁盘子系统的最大IO能力。

Max Throughput：
测试读取尺寸为64KB，100%读取操作，随机率为0%，即为100%连续读取，用于检测磁盘子系统的最大吞吐量。

OLTP：
OLTP事务处理专门用于处理实时交易过程中的管理、审计和入册过程。类似的应用实例有复杂的航空票务系统和金融交易系统等。缘其自然，OLTP是一种具有高度随机性的读写输入输出应用，其读写比例为2：1。
最后，测试读取尺寸为8KB，67%读取操作，随即率为100%。

FielServer：
文件服务器应用在一个多用户或网络化的环境中专门用于文件的储存，恢复和管理。不同用户的访问形成了多线程，因此，其工作负载是随机性的。输入输出大小是可变的，取决于所操作的文件大小。读/写分布也是变化的。总的来说，一个频繁使用的多用户服务器应该采用较高的队列深度来模拟。
最后，测试读取尺寸从512Bytes到64KB不等，80%读取操作，随机率为100%，用于模拟文件服务器的性能。

WebServer：
网站服务器应用于处理多用户通过Internet或Intranet进行的访问。这些请求具有典型的随机性，并且在用户访问不同页面或视频应用时大量偏向于读请求。同样，一个访问频繁网站服务器也应该采用较高的队列深度来模拟。
最后，测试读取尺寸从512Bytes到512KB不等，100%读取操作，随机率为100%，用于模拟Web服务器的性能。

测试时，队列深度从1到128，我们仅仅使用了一个Worker，因为对硬盘而言，无论多少个Worker硬盘都不会注意，硬盘看到的，不过是一连串的IO流。

还有一点需要注意的是我们测试的服务器总共具有4个CPU（逻辑的，非逻辑的），而给出的CPU占用率是整个系统的占用率，当系统只有一个CPU时，其CPU占用率将会比给出的数值要大。

Default

　　MBps也很平稳地随着Queue Depth提升而提升。

　　Average Response Time的提升相对较慢，尽管曲线看起来比较陡，那是因为Queue Depth是按幂递增的关系。

　　% CPU Utilization几乎可以忽略不计。

Max IO

　　前面随着Queue Depth提升而提升，在Queue Depth达到4的时候，IOps达到了一个极大值，在8的时候略微降低，这个应该是跟LSI SCSI芯片的工作方式有关。之后，IOps在Queue Depth为32的时候达到极大值21275。

　　MBps和IOps类似。

　　Max IO这样的Micro Operate的Average Response Time很低

　　和IOps曲线相像，CPU占用率随着IOps提升而提升,在Queue Depth为4时达到了最大值13.7258%。随后CPU占用率随着Queue Depth提升而降低。

Max Throughput

　　在Queue Depth不大于32的时候，IOps都大于1000，64 Queue Depth以上则掉落到800多。

　　可见，最大吞吐量在Queue Depth为8的时候达到了68.1453MB/s。

　　Average Response Time。

% CPU Utilization很低。

接下来的OLTP、FileServer、WebServer的曲线很平稳。
OLTP