2. 寫入延遲曲線分析： 基本同單條記錄插入場景。
建議
根據(jù)圖表顯示，插入為主的場景下用戶可以根據(jù)業(yè)務實際情況選擇500左右的線程數(shù)來執(zhí)行。
查詢?yōu)橹?/p>
測試參數(shù)
總記錄數(shù)為10億，分為128個region，均勻分布在4臺region server上;查詢插入操作共執(zhí)行4千萬次;查詢請求分布遵從zipfian分布;
測試結(jié)果
資源使用情況
圖17為線程數(shù)在1000時IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達到使用上限。
結(jié)果分析
基本分析見單純查詢一節(jié)，原理類似。
建議
根據(jù)圖表顯示，查詢?yōu)橹鞯膱鼍跋掠脩艨梢愿鶕?jù)業(yè)務實際情況選擇100~500之間的線程數(shù)來執(zhí)行。
Increment 自增
測試參數(shù)
1億條數(shù)據(jù)，分成16個Region，分布在4臺RegionServer上;操作次數(shù)為100萬次;
測試結(jié)果
結(jié)果分析
1. 線程數(shù)增加，Increment操作的吞吐量會不斷增加，線程數(shù)到達100個左右時，吞吐量會達到頂峰(23785 ops/sec)，之后再增加線程數(shù)，吞吐量基本維持不變;
2. 隨著線程數(shù)增加，Increment操作的平均延遲會不斷增加。線程數(shù)在100以下，平均延時都在4ms以內(nèi);
建議
根據(jù)圖表顯示，查詢?yōu)橹鞯膱鼍跋掠脩艨梢愿鶕?jù)業(yè)務實際情況選擇100~500之間的線程數(shù)來執(zhí)行。
測試結(jié)果總結(jié)
根據(jù)以上測試結(jié)果和資源利用情況可以得出如下幾點：
1. 寫性能：集群吞吐量最大可以達到70000+ ops/sec，延遲在幾個毫秒左右。網(wǎng)絡帶寬是主要瓶頸，如果將千兆網(wǎng)卡換成萬兆網(wǎng)卡，吞吐量還可以繼續(xù)增加，甚至達到目前吞吐量的兩倍。
2. 讀性能：很多人對HBase的印象可能都是寫性能很好、讀性能很差，但實際上HBase的讀性能遠遠超過大家的預期。集群吞吐量最大可以達到26000+，單臺吞吐量可以達到8000+左右，延遲在幾毫秒～20毫秒左右。IO和CPU是主要瓶頸。
3. Range 掃描性能：集群吞吐量最大可以達到14000左右，系統(tǒng)平均延遲在幾毫秒～60毫秒之間(線程數(shù)越多，延遲越大);其中IO和網(wǎng)絡帶寬是主要瓶頸。
測試注意事項
1. 需要關(guān)注是否是全內(nèi)存測試，全內(nèi)存測試和非全內(nèi)存測試結(jié)果相差會比較大。參考線上實際數(shù)據(jù)情況，本次測試采用非全內(nèi)存讀測試。是否是全內(nèi)存讀取決于總數(shù)據(jù)量大小、集群Jvm內(nèi)存大小、Block Cache占比、訪問分布是否是熱點訪問這四者，在JVM內(nèi)存大小以及Block Cache占比不變的情況下，可以增大總數(shù)據(jù)量大小或者修改訪問分布;
2. 測試客戶端是否存在瓶頸。HBase測試某些場景特別耗費帶寬資源，如果單個客戶端進行測試很可能會因為客戶端帶寬被耗盡導致無法測出實際服務器集群性能。本次測試使用6個客戶端并發(fā)進行測試。
3. 單條記錄大小對測試的影響。單條記錄設(shè)置太大，會導致并發(fā)插入操作占用大量帶寬資源進而性能產(chǎn)生瓶頸。而設(shè)置太小，測試出來的TPS峰值會比較大，和線上實際數(shù)據(jù)不符。本次測試單條數(shù)據(jù)大小設(shè)置為50M，基本和實際情況相符。