客戶端和Redis使用TCP協議連接。不論是客戶端向Redis發生命令還是Redis向客戶端返回命令的執行結果，都需要經過網絡傳輸，這兩個部分的總耗時稱往返時延。如果執行較多的命令，每個命令的往返時延累加起來對性能還是有一定影響的。在執行多個命令時每條命令都需要等待上一條命令執行完（即收到Redis的返回結果）才能執行，即使命令不需要上一條命令的執行結果，如下圖：
Redis的底層通信協議對管道（pipelining）提供了支持。通過管道可以一次性發送多條命令並在執行完後一次性將結果返回，如下圖；
管道壓力測試
Redis自帶了一個壓力測試工具 redis-benchmark 使用這個工具就可以進行管道測試。首先我們對一個普通的set指令進行壓測，QPS大約5w/s
> redis-benchmark -t set -q
SET: 51975.05 requests per second
我們加入管道選項 -P參數，它表示單個管道內並行的請求數量，看下面 p=2 ,QPS 達到了 9w/s。
> redis-benchmark -t set -P 2 -q
SET: 91240.88 requests per second
再看看 P=3，QPS 達到了 10w/s。 SET: 102354.15 requests per second
但如果再繼續提升 P 參數，發現 QPS 已經上不去了。這是爲什麼呢？ 因爲這裏 CPU 處理能力已經達到了瓶頸，Redis 的單線程 CPU 已經飆到了 100%，所以無法再繼續提升了