我们已经测试了多个SAN厂商的多种产品。并且展示了一些低并发场景下的典型测试结果。

        具体的SAN厂商名字和配置做了保密处理，但是可以透露的是这些都不是便宜的SAN。测试都是用同步的16 KB操作，模拟InnoDB配置在0_DIRECT模式时的操作方式。

        我们测试的系统不是都可以直接比较的，所以盯着这些好看的数据点来看不能客观地做出评价。然而，这些结果很好地说明了这类设备的总体性能表现，SAN可以承受大量的连续写人，因为可以缓冲并合并I/O. SAN提供顺序读取没有问题，因为可以做预读并从缓存中提出数据。在随机写上会慢一些，因为写入操作不能较好地合并。因为读取通常在缓存中无法命中，必须等待硬盘驱动器响应，所以SAN很不适合做随机读取。最重要的是，服务器和SAN之间有传输延迟。这是为什么通过NFS连接SAN时，提供的每秒随机读还不如一块本地磁盘的原因。

        我们已经用较大尺寸的文件做了基准测试，但没有用其他尺寸的文件在上述的系统中测试。然而，无论结果如何，可以预见的是:不管多么强大的SaN,对于小的随机操作，都无法获得良好的响应时间和吞吐量。延时的大部分都是由于服务器和San之间的链路导致的。

        我们的基准测试显示的每秒操作吞吐量，并没有说出完整的故事。至少有三个重要指标:每秒吞吐量字节数、并发性和响应时间。在一般情况下， 相对于直接连接存储(DAS).SAN无论读写都可以提供更好的顺序I/O吞吐量。大多数SAN可以支持大量的并发性。但基准测试只有一个线程，这可以说明最坏的情况。但是，当工作集不能放到SAN的缓存时，随机读在吞吐量和延迟方面将变得很差，甚至延迟将高于直接访向本地存储。