從我們的直觀感受來講，對于任何服務(wù)，只要在中間增加了一層，肯定會對服務(wù)性能造成影響。那么到底會影響什么呢？在考察一個服務(wù)性能的時候，有兩個最重要的指標(biāo)，那就是吞吐和延遲。吞吐定義為服務(wù)端單位時間內(nèi)能處理的請求數(shù)，延遲定義為客戶端從發(fā)出請求到收到請求的耗時。中間環(huán)節(jié)的引入我們首先想到的就是那會增加處理時間，這就會增加服務(wù)的延遲，于是順便我們也會認(rèn)為吞吐也會下降。從單個用戶的角度來講，事實確實如此，我完成一個請求的時間增加了，那么我單位時間內(nèi)所能完成的請求量必定就減少了。然而站在服務(wù)端的角度來看，雖然單個請求的處理時間增加了，但是總的吞吐就一定會減少嗎？

接下來我們就來對redis來進(jìn)行一系列的測試，利用redis自帶的redis-benchmark，分別對set和get命令；單個發(fā)送和批量發(fā)送；直連redis和連接redis代理predixy。這樣組合起來總共就是八種情況。redis-benchmark、redis是單線程的，predixy支持多線程，但是我們也只運行一個線程，這三個程序都運行在一臺機(jī)器上。

項目 內(nèi)容
CPU?AMD Ryzen 7 1700X Eight-Core Processor 3.775GHz?
內(nèi)存?16GB DDR4 3000?
OS?x86_64 GNU/Linux 4.10.0-42-generic #46~16.04.1-Ubuntu?
redis?版本3.2.9，端口7200?
predixy?版本1.0.2，端口7600?

八個測試命令

測試命令 命令行
redis set?redis-benchmark -h xxx -p 7200 -t set -r 3000 -n 40000000?
predixy set?redis-benchmark -h xxx -p 7600 -t set -r 3000 -n 40000000?
redis get?redis-benchmark -h xxx -p 7200 -t get -r 3000 -n 40000000?
predixy get?redis-benchmark -h xxx -p 7600 -t get -r 3000 -n 40000000?
redis 批量set?redis-benchmark -h xxx -p 7200 -t set -r 3000 -n 180000000 -P 20?
predixy 批量set?redis-benchmark -h xxx -p 7600 -t set -r 3000 -n 180000000 -P 20?
redis 批量get?redis-benchmark -h xxx -p 7200 -t get -r 3000 -n 420000000 -P 20?
predixy 批量get?redis-benchmark -h xxx -p 7600 -t get -r 3000 -n 220000000 -P 20?

以上8條命令采取redis-benchmark默認(rèn)的50個并發(fā)連接，數(shù)據(jù)大小為2字節(jié)，指定3000個key，批量測試時一次發(fā)送20個請求。依次間隔2分鐘執(zhí)行以上命令，每一個測試完成時間大約4分鐘。最后得到下圖的總體結(jié)果：

眼花繚亂是不是？左邊的縱軸表示CPU使用率，右邊的縱軸表示吞吐。其中redis used表示redis總的CPU使用率，redis user表示redis CPU用戶態(tài)使用率，redis sys表示redis CPU內(nèi)核態(tài)使用率，其它類推。先別擔(dān)心分不清里面的內(nèi)容，下面我們會一一標(biāo)出數(shù)值來。在這圖中總共可以看出有八個凸起，依次對應(yīng)我們上面提到的八個測試命令。

1 redis set測試

2 predixy set測試

3 redis get測試

4 predixy get測試

5 redis 批量set測試