KMS 对 HDFS 性能影响测试报告

测试环境

测试使用现网机器，各项指标如下，KMS Server 所使用的 JVM 参数均取默认值（KMS Server 并非内存占用型进程，内存、GC 等配置并非必要）。

项目	数值
CPU	24核 Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
内存	64G

KMS 对 NameNode 性能的影响

NameNode在创建一个加密文件时，需要为该文件分配一个 EDEK，这个操作需要和 KMS Server 产生 http 交互（配置了缓存的情况下不需要每次都交互），因此，增加 KMS 组件后，可能会对 NameNode 的创建性能产生影响。

测试方法

使用 NNBench，分别在正常目录和加密目录连续创建 30W 个大小为0的文件。
在 NameNode 端，使用 Btrace 工具，统计 NameNodeRpcServer.create() 调用的耗时情况。
NameNode 端，一次获取的 EDEK 个数保持默认值（500），KMS Server 端，一次生产并缓存的 EDEK 个数保持默认值（100）。
NameNode 和 KMS Server部署在同一台测试机器上，因此，网络延迟并没有计入考虑。

测试结果

项目	NameNodeRpcServer.create()总耗时(s)	NameNodeRpcServer.create()平均耗时(us)
正常目录	19.70	65.66
加密目录	34.41	114.70

测试结论

可以看到，连续创建30W个文件，NameNode 的处理时间增加了15s左右。
目前现网环境，NameNode 处理的 create 请求量的峰值大概在 50W/h，换句话说，接入 KMS 后，NameNode 原本 1h 的任务量，现在需要 1h零15s 来完成，这个增长微乎其微，基本可以忽略。

KMS 对 HDFS 客户端性能的影响

KMS 对客户端的影响体现在两个方面：

客户端写入加密文件时，需要在本地 JVM 中完成加密运算。
客户度读取加密文件时，均需要在本地 JVM 中完成解密运算。
因此，增加加密功能后，肯定会对客户端的读写效率有一定的影响。

客户端写性能影响

1. 测试方法

使用 NNBench 工具，分别在正常目录和加密目录中，连续写入100个大小为2G的文件，blockSize 取默认的 128M，分别统计使用 java 加密库和 native 加密库时的结果。
NNBench 和 KMS Server部署在同一台测试机器上，排除网络延迟影响，只关注加解密性能。
写入时使用1副本，排除流水线影响，只关注加解密性能。
测试命令，假设正常目录为 /normal，加密目录为 /ez，则两条命令如下：
- 写正常目录
  bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.2.jar nnbench -operation create_write -maps 1 -reduces 1 -blockSize 134217728 -bytesToWrite 2147483640 -bytesPerChecksum 512 -numberOfFiles 100 -baseDir /normal/NNBench-`hostname -s` -startTime $(($(date +'%s')+20))
- 写加密目录
  bin/hadoop jar ./share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-2.7.2.jar nnbench -operation create_write -maps 1 -reduces 1 -blockSize 134217728 -bytesToWrite 2147483640 -bytesPerChecksum 512 -numberOfFiles 100 -baseDir /ez/NNBench-`hostname -s` -startTime $(($(date +'%s')+20))

2. 测试结果

使用 Java 库进行加密（左边为正常写，右边为加密写）：

使用 native 加密库（libssl-devel)进行加密（左边为正常写，右边为加密写）：

3. 测试结论

使用 Java 加密库时，平均写耗时从 9.47s 增加到 14.98s，写性能降低 58%.
使用 Native 加密库时，平均写耗时从 10.81s 增加到 11.71s，写性能降低 8%.

客户端读性能影响