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

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

項目 內容
CPU?AMD Ryzen 7 1700X Eight-Core Processor 3.775GHz?
內存?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默認的50個并發連接，數據大小為2字節，指定3000個key，批量測試時一次發送20個請求。依次間隔2分鐘執行以上命令，每一個測試完成時間大約4分鐘。最后得到下圖的總體結果：

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

1 redis set測試

2 predixy set測試

3 redis get測試

4 predixy get測試

5 redis 批量set測試