上图为单台RegionServer的带宽使用曲线图(资源使用情况中只列出和本次测试相关的资源曲线图，后面相关资源使用情况类似)，本次测试线程为1000的情况下带宽基本维持在100M左右，对于百兆网卡来说基本上已经打满。
结果分析
1. 吞吐量曲线分析：线程数在10~500的情况下，随着线程数的增加，系统吞吐量会不断升高;之后线程数再增加，系统吞吐量基本上不再变化。结合图3带宽资源使用曲线图可以看出，当线程数增加到一定程度，系统带宽资源基本耗尽，系统吞吐量就不再会增加。 可见， HBase写操作是一个带宽敏感型操作，当带宽资源bound后，写入吞吐量基本就会稳定。
2. 写入延迟曲线分析：随着线程数的不断增加，写入延迟也会不断增大。这是因为写入线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低;另一方面由于线程之间可能会存在互斥操作导致线程阻塞;这些因素都会导致写入延迟不断增大。
建议
根据曲线显示，500线程以内的写入延迟并不大于10ms，而此时吞吐量基本最大，因此如果是单纯写入的话500线程写入会是一个比较合适的选择。
单纯查询
测试参数
总记录数为10亿，分为128个region，均匀分布在4台region server上;查询操作执行2千万次;查询请求分布遵从zipfian分布;
测试结果
资源使用情况
图5为线程数在1000时IO利用率曲线图，图中IO利用率基本保持在100%，说明IO资源已经达到使用上限。图6为线程数在1000时系统负载曲线图，图中load1曲线表示在最近一分钟内的平均负载，load5表示最近五分钟内的平均负载。最近5分钟的负责达到了50左右，对于32核系统来说，表示此时系统负载很高，已经远远超负荷运行。
结果分析
1. 吞吐量曲线分析：线程数在10~500的情况下，随着线程数的增加，系统吞吐量会不断升高;之后线程数再增加，系统吞吐量基本上不再变化。结合图5、图6系统资源使用曲线图可以看出，当线程数增加到一定程度，系统IO资源基本达到上限，系统负载也特别高。IO利用率达到100%是因为大量的读操作都需要从磁盘查找数据，系统负载很高是因为HBase需要对查找的数据进行解压缩操作，解压缩操作需要耗费大量CPU资源。这两个因素结合导致系统吞吐量就不再随着线程数增肌而增加。可见，HBase读操作是一个IO/CPU敏感型操作，当IO或者CPU资源bound后，读取吞吐量基本就会稳定不变。
2. 延迟曲线分析：随着线程数的不断增加，读取延迟也会不断增大。这是因为读取线程过多，导致CPU资源调度频繁，单个线程分配到的CPU资源会不断降低;另一方面由于线程之间可能会存在互斥操作导致线程阻塞;这些因素都会导致写入延迟不断增大。和写入延迟相比，读取延迟会更大，是因为读取涉及IO操作，IO本身就是一个耗时操作，导致延迟更高。
建议
根据曲线显示，500线程以内的读取延迟并不大于20ms，而此时吞吐量基本最大，因此如果是单纯读取的话500线程读取会是一个比较合适的选择。
Range 扫描查询
测试参数
总记录数为10亿，分为128个region，均匀分布在4台region server上;scan操作执行一千两百万次，请求分布遵从zipfian分布; scan最大长度为100条记录， scan长度随机分布且遵从uniform分布;
测试结果
资源使用情况
图8为线程数在1000时IO利用率曲线图，图中IO利用率基本保持在100%，说明IO资源已经达到使用上限。图9为线程数在1000时带宽资源使用曲线图，图中带宽资源基本也已经达到上限。