HBase 压力测试

测试环境：

3台RegionServer,每台的配置如下：

cpu:    32 core

mem:  48 GB，每台RS分配16GB

RS RPC Handler: 300

Test-1 Random Read:

随机读压力
OperationType		RandomRead Latency			BlockCacheHitRation	Rpc.Call.Queue
client随机读线程数量	ClusterQps	Average(ms)	95线(ms)	99线(ms)
50	9003	6	19	37	80%	~
100	11956	9	34	76	80%	~
200	18496	11	53	139	80%	~
300	21206	15	74	176	80%	~
400	23089	18	94	233	80%	~
500	24380	22	106	286	80%	40
600	24805	26	115	302	80%	100
300*(2 client)	25225	26	110	310	80%	120
200*(3 client)	24938	26	110	317	80%	150
800	18823	46	182	403	80%	300

由于测试操作是在对数据blockcache进行了预热操作，所以每次测试的缓存命中率都在80%左右，去除了缓存对读性能的影响。从上述测试数据看出，随着client读线程数量的增加，HBase集群的Qps逐渐升高，同时平均读延迟有所升高，但是在500个线程之前的访问延迟都是可以接受的。在600个线程之后的访问中，Qps逐渐减低，延迟增大，主要原因就是RegionServer的RPC.CallQueue逐渐增大，即RS的RPCHandler(300个)不足与承担此时的Qps压力。

Test-2 Random & Scan Read:

混合压力
OperationType		RandomRead Latency	Scan	BlockCacheHitRation	Rpc.Call.Queue
client随机读线程数量	ClusterQps	Average(ms)	Average(ms)	Average(%)	Average(个)
100*(2client)	140000	22	800	75%	<5
200*(2client)	151500	40	1500	75%	60
300*(2client)	192700	70	1800	75%	330
400*(2client)	204000	100	2000	75%	340

Test-2的压力模式，主要是大概模拟HBase1号集群的访问：

readproportion=0.3 30%的随机读

updateproportion=0.1 10%的更新操作

scanproportion=0.3 30%的scan

insertproportion=0.1 10%的插入

readmodifywriteproportion=0.2 20%的读取修改然后写入操作

    丛数据看出，随着访问线程数目的增加，Qps剧烈增加，同时随机读延迟/scan延迟都在增加，因为RPC.CallQueue的增加。

    假设随机读延迟在50ms左右为可接受时，那么当此集群Qps达到150000(可能会在多点)时，就需要开始关注RPC.CallQueue的数量，如果只是某台RS的RPC.CallQueue数量比较高，先考虑是否是HotRegion引起的；如果大部分RS的RPC.CallQueue数量一直比较高，就需要考虑添加机器来缓解压力。