結(jié)果分析
1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖8 、圖9資源使用曲線圖可以看出，當線程數(shù)增加到一定程度，系統(tǒng)IO資源基本達到上限，帶寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁盤查找數(shù)據(jù)，而帶寬負載很高是因為每次scan操作最多可以獲取50Kbyte數(shù)據(jù)，TPS太高會導致數(shù)據(jù)量很大，因而帶寬負載很高。兩者結(jié)合導致系統(tǒng)吞吐量就不再隨著線程數(shù)增大會增大?？梢?，scan操作是一個IO/帶寬敏感型操作，當IO或者帶寬資源bound后，scan吞吐量基本就會穩(wěn)定不變。
2. 延遲曲線分析：隨著線程數(shù)的不斷增加，讀取延遲也會不斷增大。這是因為讀取線程過多，導致CPU資源調(diào)度頻繁，單個線程分配到的CPU資源會不斷降低;另一方面由于線程之間可能會存在互斥操作導致線程阻塞;這些因素都會導致寫入延遲不斷增大。和寫入延遲以及單次隨機查找相比，讀取延遲會更大，是因為scan操作會涉及多次IO操作，IO本身就是一個耗時操作，因此會導致延遲更高。
建議
根據(jù)圖表顯示，用戶可以根據(jù)業(yè)務(wù)實際情況選擇100~500之間的線程數(shù)來執(zhí)行scan操作。
查詢插入平衡
測試參數(shù)
總記錄數(shù)為10億，分為128個region，均勻分布在4臺region server上;查詢插入操作共執(zhí)行8千萬次;查詢請求分布遵從zipfian分布;
測試結(jié)果
資源使用情況
圖11為線程數(shù)在1000時系統(tǒng)IO利用率曲線圖，圖中IO利用率基本保持在100%，說明IO資源已經(jīng)達到使用上限。圖12為線程數(shù)在1000時系統(tǒng)負載曲線圖，圖中顯示CPU負載資源達到了40+，對于只有32核的系統(tǒng)來說，已經(jīng)遠遠超負荷工作了。
結(jié)果分析
1. 吞吐量曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量變化就比較緩慢。結(jié)合圖11、圖12系統(tǒng)資源使用曲線圖可以看出，當線程數(shù)增加到一定程度，系統(tǒng)IO資源基本達到上限，帶寬也基本達到上限。IO利用率達到100%是因為大量的讀操作都需要從磁盤查找數(shù)據(jù)，而系統(tǒng)負載很高是因為大量讀取操作需要進行解壓縮操作，而且線程數(shù)很大本身就需要更多CPU資源。因此導致系統(tǒng)吞吐量就不再會增加?？梢姡樵儾迦肫胶鈭鼍跋?，當IO或者CPU資源bound后，系統(tǒng)吞吐量基本就會穩(wěn)定不變。
2. 延遲曲線分析：隨著線程數(shù)的不斷增加，讀取延遲也會不斷增大。這是因為讀取線程過多，導致CPU資源調(diào)度頻繁，單個線程分配到的CPU資源會不斷降低;另一方面由于線程之間可能會存在互斥操作導致線程阻塞;這些因素都會導致寫入延遲不斷增大。圖中讀延遲大于寫延遲是因為讀取操作涉及到IO操作，比較耗時。
建議
根據(jù)圖表顯示，在查詢插入平衡場景下用戶可以根據(jù)業(yè)務(wù)實際情況選擇100~500之間的線程數(shù)。
插入為主
測試參數(shù)
總記錄數(shù)為10億，分為128個region，均勻分布在4臺region server上;查詢插入操作共執(zhí)行4千萬次;查詢請求分布遵從latest分布;
測試結(jié)果
資源使用情況
圖15為線程數(shù)在1000時系統(tǒng)帶寬使用曲線圖，圖中系統(tǒng)帶寬資源基本到達上限，而總體IO利用率還比較低。
結(jié)果分析
1. 曲線分析：線程數(shù)在10~500的情況下，隨著線程數(shù)的增加，系統(tǒng)吞吐量會不斷升高;之后線程數(shù)再增加，系統(tǒng)吞吐量基本上不再變化。結(jié)合圖14帶寬資源使用曲線圖可以看出，當線程數(shù)增加到一定程度，系統(tǒng)帶寬資源基本耗盡，系統(tǒng)吞吐量就不再會增加。基本同單條記錄插入場景相同。