1. 线程数增加，Increment操作的吞吐量会不断增加，线程数到达100个左右时，吞吐量会达到顶峰（23785 ops/sec），之后再增加线程数，吞吐量基本维持不变;
2. 随着线程数增加，Increment操作的平均延迟会不断增加。线程数在100以下，平均延时都在4ms以内；
建议
根据图表显示，查询为主的场景下用户可以根据业务实际情况选择100~500之间的线程数来执行。
测试结果总结
根据以上测试结果和资源利用情况可以得出如下几点：
1. 写性能：集群吞吐量最大可以达到70000+ ops/sec，延迟在几个毫秒左右。网络带宽是主要瓶颈，如果将千兆网卡换成万兆网卡，吞吐量还可以继续增加，甚至达到目前吞吐量的两倍。
2. 读性能：很多人对HBase的印象可能都是写性能很好、读性能很差，但实际上HBase的读性能远远超过大家的预期。集群吞吐量最大可以达到26000+，单台吞吐量可以达到8000+左右，延迟在几毫秒～20毫秒左右。IO和CPU是主要瓶颈。
3. Range 扫描性能：集群吞吐量最大可以达到14000左右，系统平均延迟在几毫秒～60毫秒之间（线程数越多，延迟越大）；其中IO和网络带宽是主要瓶颈。
测试注意事项
1. 需要关注是否是全内存测试，全内存测试和非全内存测试结果相差会比较大。参考线上实际数据情况，本次测试采用非全内存读测试。是否是全内存读取决于总数据量大小、集群Jvm内存大小、Block Cache占比、访问分布是否是热点访问这四者，在JVM内存大小以及Block Cache占比不变的情况下，可以增大总数据量大小或者修改访问分布；
2. 测试客户端是否存在瓶颈。HBase测试某些场景特别耗费带宽资源，如果单个客户端进行测试很可能会因为客户端带宽被耗尽导致无法测出实际服务器集群性能。本次测试使用6个客户端并发进行测试。
3. 单条记录大小对测试的影响。单条记录设置太大，会导致并发插入操作占用大量带宽资源进而性能产生瓶颈。而设置太小，测试出来的TPS峰值会比较大，和线上实际数据不符。本次测试单条数据大小设置为50M，基本和实际情况相符。