测试环境

一共使用10台现网机器，配置如下，另外，NN、DN 的 JVM 参数也和现网保持一致。

测试方法

设计多个场景，在每个场景下分别进行读写测试：

1. 写测试，使用 TestDFSIO 连续串行写入100个大小为2GB的文件，统计结果，命令如下：
   HADOOP_CLIENT_OPTS="-Xmx10G -Xms10G" bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.8.5.jar TestDFSIO -write -nrFiles 100 -size 2GB

2. 读测试，使用 TestDFSIO 连续串行读取100个大小为2GB的文件，统计结果，命令如下：
   HADOOP_CLIENT_OPTS="-Xmx10G -Xms10G" bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.8.5.jar TestDFSIO -read -nrFiles 100 -size 2GB

注意：

1. 每次执行测试前，都需要执行 sync && echo 3 > /proc/sys/vm/drop_caches 释放文件系统缓存，保证多次测试的独立性。
2. 针对 EC 场景，需要分别统计使用 Java 编码库和 Intel ISA-L Native 编码库的性能表现。
3. 下面测试结果中的 “耗时” 项指的是整个 TestDFSIO 的执行耗时（包括 MR 任务的提交、结果的分析等等），该耗时仅作参考。真正的结果应以 “平均 IO 速率” 这一项为准。

使用 ISA-L Native 编码库的测试结果

正常写入场景

正常读取场景

异常读取场景

使用纯 Java 编码库的测试结果

正常写入场景

正常读取场景

异常读取场景

客户端机器网络带宽使用率(仅测试使用 ISA-L 加速库的情形)

客户端进程 CPU 使用率(仅测试使用 ISA-L 加速库的情形)

注意：这里的 cpu 使用率使用 top -p $PID 统计得到，是所有 CPU 核的累加使用率，对于一个96核的 CPU 来说，该值最大可以到 9600%.

测试结论

1. ISA-L Native 加速库非常关键，如果没有这个加速库，EC 写性能仅能达到副本写的 30% 左右。因此，下面所有的结论都针对使用 ISA-L 加速库的情形。
2. EC 会显著增加客户端机器的网络带宽和 CPU 消耗，以 6+3 为例，相比正常的3副本：
   1. 客户端写入过程中，理论上它的带宽使用会增长9倍，但受限于磁盘写入速度、交换机速度等因素，具体增长程度可能较低，本次测试中增长2倍。
   2. 客户端读取过程中，理论上它的带宽使用会增长6倍，同样，受限于磁盘读取速度、交换机速度等因素，具体增加程度可能较低，本次测试中增长4倍。
   3. 客户端写入过程中，由于并发写入且需要计算 EC 校验值，其 CPU 使用率会显著增长，本次测试中增长7倍。
   4. 客户端读取过程中，由于并发读取，其 CPU 使用率也会显著增长，本次测试中增长6倍。
3. EC 并不会降低客户端的 IO 速度，反而，在其它关键要素都满足的情况下（主要是 CPU 和 网络），EC 会提升 IO 速度，特别是显著提升读取速度，以 6+3 为例：
   1. 客户端写入过程中，虽然增加了计算校验值的步骤，但是在 ISA-L 的帮助下，这部分耗时并不多，完全可以被之后的9倍并发写找补回来，在本次测试中，客户端 EC 写入速度比3副本提升了 5% 左右。
   2. 客户端读取过程中，EC 的6倍并发读完全压过了3副本的单线程读，在本次测试中，EC 读速度比3副本本地读提升了300%，这其中的原因是：单线程读完全受制于磁盘的极限读取速度（190MB/s左右），反观6倍并发读不受此限制。
4. EC 在正常读取和修复读取两种情况下，速度差别不大，以 6+3 为例：
   1. 无论是正常读取还是修复读取，客户端都是固定的6倍并发读6 个 DN，不会随着挂掉的 DN 个数变化而变化。
   2. 在 ISA-L 帮助下，异常读取时的修复时间（即计算出原始数据的时间）很短。
5. 以上的结果都是在网络和 CPU 完全足够的情况下测得的，特别是网络，本次测试中所有机器都配置了一个50Gb 的 bond 网卡（由两张 25Gb 的物理网卡聚合而成），完全够用。但在真实场景下，CPU、网络可能达不到本次测试的理想条件，因此结果也可能会有出入。