比较分布式文件系统，只需关注小的同步写

Jeff Darcy个人发布的分布式存储测试分析报告为什么只关注Small Synchronous Writes     

原文：http://pl.atyp.us/2013-07-why-sync-writes.html

    肯定有其他op的性能需要考虑。但是其他op不能得出两个分布式文件系统的不同，只有这个小的同步写可以。

原因如下：

1、读op的负载测试不行：

    a、os和或者app级别的缓存把read进行了屏蔽，压力传递不到分布式文件系统级别。在文件系统级别，只关注write op。read cache意义不小，但引来较大的延迟。

    b、只有大的顺序读是个例外，没有缓存的影响，但是大读容易饱和网络带宽，所以看不出两个文件系统的差别。

2、其他类型的写：

    大的写或者大的异步写，大多数情况下也排除了cache的影响，但是也会饱和带宽，看不出两个文件系统的差别，跟大的读一样。也有可能批处理写或者合并写，这样也饱和了网络。重要的是测试同时的多个独立请求，分布式文件系统的并行处理能力。

3、就剩下了小的同步写：

    对于此操作，在分布式文件系统评估阶段，对于函数生成元数据，算法定位的系统比如glusterfs／ceph，可以从单客户和单服务器的性能初步推断出系统的扩展性能。

    对于基于目录来定位的分布式文件系统hdfs／lustre，扩展性受到元数据服务器的影响。

4，应该也考虑元数据op的性能：

文件create和目录list性能比小写更差。也应该报告这样的测试数据。

    测试小的同步写，是测试的最佳开始点。对于个人评估测试，可以考虑这样。但是对于要部署的系统，应该测试各种负载并且尽量跟真实环境一致。

转自：http://blog.csdn.net/inevity/article/details/19556467