當用戶連接到Redis通過TCP/IP連接或Unix域連接，千兆網 絡的典型延遲大概200us，而Unix域socket可能低到30us。這完全基于你的網絡和系統硬件。在通信本身之上，系統增加了更多的延遲(線程調 度，CPU緩存，NUMA替換等等)。系統引起的延遲在虛擬機環境遠遠高于在物理機器環境。

　　實際情況是即使Redis處理大多數命令在微秒之下，客戶機和服務器之間的交互也必然消耗系統相關的延遲。

　　一個高效的客戶機因而試圖通過捆綁多個命令在一起的方式減少交互的次數。服務器和大多數客戶機支持這種方式。聚合命令象MSET/MGET也可以用作這個目的。從Redis 2.4版本起，很多命令對于所有的數據類型也支持可變參數。

　　這里有一些指導：

• 如果你負擔的起，盡可能的使用物理機而不是虛擬機來做服務器
• 不要經常的connect/disconnect與服務器的連接(尤其是對基于web的應用)，盡可能的延長與服務器連接的時間。
• 如果你的客戶端和服務器在同一臺主機上，則使用Unix域套接字
• 盡量使用聚合命令(MSET/MGET)或可變參數命令而不是pipelining
• 如果可以盡量使用pipelining而不是序列的往返命令。
• 針對不適合使用原始pipelining的情況，如某個命令的結果是后續命令的輸入，在以后的版本中redis提供了對服務器端的lua腳本的支持，實驗分支版本現在已經可以使用了。

　 　在Linux上，你可以通過process placement(taskset)、cgroups、real-time priorities(chrt)、NUMA配置(numactl)或使用低延遲內核的方式來獲取較低的延遲。請注意Redis 并不適合被綁到單個CPU核上。redis會在后臺創建一些非常消耗CPU的進程，如bgsave和AOF重寫，這些任務是絕對不能和主事件循環進程放在 一個CPU核上的。

　　大多數情況下上述的優化方法是不需要的，除非你確實需要并且你對優化方法很熟悉的情況下再使用上述方法。

　　Redis 使用了單線程的設計， 意味著單線程服務于所有的客戶端請求，使用一種復用的技術。這種情況下redis可以在任何時候處理單個請求， 所以所有的請求是順序處理的。這和Node.js的工作方式很像， 所有的產出通常不會有慢的感覺，因為處理單個請求的時間非常短，但是最重要的是這些產品被設計為非阻塞系統調用，比如從套接字中讀取或寫入數據。

　　我提到過Redis從2.4版本后幾乎是單線程的，我們使用線程在后臺運行一些效率低下的I/O操作， 主要關系到硬盤I/O，但是這不改變Redis使用單線程處理所有請求的事實。

　　低效操作產生的延遲

　　單線程的一個結果是，當一個請求執行得很慢，其他的客 戶端調用就必須等待這個請求執行完畢。當執行GET、SET或者LPUSH 命令的時候這不是個問題，因為這些操作可在很短的常數時間內完成。然而，對于多個元素的操作，像SORT,LREM, SUNION 這些，做兩個大數據集的交叉要花掉很長的時間。

　　文檔中提到了所有操作的算法復雜性。 在使用一個你不熟悉的命令之前系統的檢查它會是一個好辦法。

　　如果你對延遲有要求，那么就不要執行涉及多個元素的慢操作，你可以使用Redis的replication功能，把這類慢操作全都放到replica上執行。

　　可以用Redis 的Slow Log來監控慢操作。

　　此外，你可以用你喜歡的進程監控程序(top, htop, prstat, 等...)來快速查看Redis進程的CPU使用率。如果traffic不高而CPU占用很高，八成說明有慢操作。

　　延遲由fork產生

　 　Redis不論是為了在后臺生成一個RDB文件，還是為了當AOF持久化方案被開啟時重寫Append Only文件，都會在后臺fork出一個進程。fork操作(在主線程中被執行)本身會引發延遲。在大多數的類unix操作系統中，fork是一個很消耗 的操作，因為它牽涉到復制很多與進程相關的對象。而這對于分頁表與虛擬內存機制關聯的系統尤為明顯

　　對于運行在一個 linux/AMD64系統上的實例來說，內存會按照每頁4KB的大小分頁。為了實現虛擬地址到物理地址的轉換，每一個進程將會存儲一個分頁表(樹狀形式 表現)，分頁表將至少包含一個指向該進程地址空間的指針。所以一個空間大小為24GB的redis實例，需要的分頁表大小為 24GB/4KB*8 = 48MB。

　　當一個后臺的save命令執行時，實例會啟動新的線程去申請和拷貝48MB的內存空間。這將消耗一些時間和CPU資源，尤其是在虛擬機上申請和初始化大塊內存空間時，消耗更加明顯。

　　在不同系統中的Fork時間

　 　除了Xen系統外，現代的硬件都可以快速完美的復制頁表。Xen系統的問題不是特定的虛擬化，而是特定的Xen.例如使用VMware或者 Virutal Box不會導致較慢的fork時間。下面的列表比較了不同Redis實例的fork時間。數據包含正在執行的BGSAVE，并通過INFO指令查看 thelatest_fork_usecfiled。

• Linux beefy VM on VMware 6.0GB RSS forked 77 微秒 (每GB 12.8 微秒 ).
• Linux running on physical machine (Unknown HW) 6.1GB RSS forked 80 微秒(每GB 13.1微秒)
• Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 微秒 (每GB 9 微秒).
• Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 微秒 (每GB 23.3 微秒).
• Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 微秒 (每GB 239.3 微秒).
• Linux VM on Linode (Xen) 0.9GBRSS forked into 382 微秒 (每GB 424 微秒).

　　你能看到運行在Xen上的VM的Redis性能相差了一到兩個數量級。我們相信這是Xen系統的一個驗證問題，我們希望這個問題能盡快處理。

　　swapping (操作系統分頁)引起的延遲

　　Linux (以及其他一些操作系統) 可以把內存頁存儲在硬盤上，反之也能將存儲在硬盤上的內存頁再加載進內存，這種機制使得內存能夠得到更有效的利用。

　　如果內存頁被系統移到了swap文件里，而這個內存頁中的數據恰好又被redis用到了(例如要訪問某個存儲在內存頁中的key)，系統就會暫停redis進程直到把需要的頁數據重新加載進內存。這個操作因為牽涉到隨機I/O，所以很慢，會導致無法預料的延遲。

　　系統之所以要在內存和硬盤之間置換redis頁數據主要因為以下三個原因：

• 系統總是要應對內存不足的壓力，因為每個運行的進程都想申請更多的物理內存，而這些申請的內存的數量往往超過了實際擁有的內存。簡單來說就是redis使用的內存總是比可用的內存數量更多。
• redis實例的數據，或者部分數據可能就不會被客戶端訪問，所以系統可以把這部分閑置的數據置換到硬盤上。需要把所有數據都保存在內存中的情況是非常罕見的。
• 一些進程會產生大量的讀寫I/O。因為文件通常都有緩存，這往往會導致文件緩存不斷增加，然后產生交換(swap)。請注意，redis RDB和AOF后臺線程都會產生大量文件。

　　所幸Linux提供了很好的工具來診斷這個問題，所以當延遲疑似是swap引起的，最簡單的辦法就是使用Linux提供的工具去確診。

　　首先要做的是檢查swap到硬盤上的redis內存的數量，為實現這個目的要知道redis實例的進程id：

　　在這里你會發現一個名為smaps 的文件，它描述了redis進程的內存布局 (假定你使用的是Linux 2.6.16或者更新的版本)。這個文件包括了很多進程所使用內存的細節信息，其中有一項叫做Swap的正是我們所關心的。不過僅看這一項是不夠的，因為 smaps文件包括有redis進程的多個不同的的內存映射區域的使用情況(進程的內存布局遠不是線性排列那么簡單)。

　　從我們對所有進程的內存交換情況感興趣以來，我們首先要做的事情是使用grep命令顯示進程的smaps文件

　　最后，可以用iostat命令來查看系統的全局I/O行為。

　　上面的命令會展示redis主線程里所有的fdatasync系統調用。不包括后臺線程執行的fdatasync 調用。如果appendfsync 配置為everysec，則給strace增加-f選項。

　　用下面命令可以看到fdatasync和write調用：

　　在所有的情況下，一旦Redis運行huge page(透明或者非透明)，將會得到如下的好處：

• 由于fork引起的延遲將得到緩解。尤其是對超大的實例，尤其是在VM上運行的實例。
• Redis速度得到提夠，是因為CPU的轉換旁視緩沖(TLB)更有效的緩存頁面(例如命中率會更高)。不要期望有奇跡發生，性能至多只能提高一點。
• Redis內存不會再被換走，這樣就能避免由于虛擬內存造成的不必的延遲。

　 　很不幸，除了更多的復雜操作，還有redis使用huge page會帶來一個明顯的缺陷。COW機制的粒度是頁面。伴隨2MB頁面，頁面被后臺存儲操作修改的可能性是4KB頁面的512倍。實際的內存需要后臺存 儲，所以可能性會增加很多，尤其是，當寫操作很隨機，并且伴隨很差的定位。通過huge page，使用兩倍的內存，而存儲將不再是理論的突發事件。它真的會發生。

　　完整的性能評估結果可以參閱鏈接：https://gist.github.com/1272254