Python--Redis實戰：第四章：數據安全與性能保障：第8節：關於性能方面的注意事項

上一篇文章： Python--Redis實戰：第四章：數據安全與性能保障：第7節：非事務型流水線
下一篇文章： Python--Redis實戰：第五章：使用Redis構建支持程序：第1節：使用Redis來記錄日誌

習慣了關係數據庫的用戶在剛開始使用Redis的時候，一般會由於Redis帶來的上百倍的性能提高而感到欣喜若狂，卻沒有認識到Redis性能實際上還能夠進一步的提升。雖然上一節介紹的非事務型流水線能夠儘量地減小應用程序和Redis之間的通訊往返次數，可是對於一個已經存在的應用程序，咱們應該如何判斷這個程序可否被優化呢？咱們又應該如何對它進行優化呢？

要對Redis的性能進行優化，用戶首先須要弄清楚各類類型的Redis命令到底能跑多快，而這一點能夠經過調用Redis附帶的性能測試程序redis-benchmark來得知，下面清單展現了一個相應的例子。若是有興趣的話，讀者也能夠試着用redis-benchmark來了解Redis在本身服務器上的各類性能特徵：

在裝有英特爾酷睿2雙核2.4GHz處理器的臺式電腦上運行redsi-benchmark

#給定‘-q’選項可讓程序簡化輸出結果，給定‘-c 1’選項讓程序只使用一個客戶端來進行測試
$ redis-benchmark -c 1 -q
PING (inline):34246.57 requests per second
Pind:34843.32 requests per second
MSET (10 keys):24213 08 request per second
SET: 32467.53 request per second
GET: 33112.59 request per second
INCR: 32679.74 request per second
LPUSH: 33333.33 request per second
LPOP: 33670.04 request per second
SADD: 33222.59 request per second
SPOP: 34482.76 request per second
LPUSH (again, in order to bench LRNAGE):33222.59 request per second
LRANGE (first 100 elements):22988.51 request per second
LRANGE (first 300 elements):13888.89 request per second
LRANGE (first 450 elements):11061.95 request per second
LRANGE (first 600 elements):9041.59 request per second

redis-benchmark的運行結果展現了一些經常使用Redis命令在1秒內能夠執行的此時。若是用戶在不給定任何參數的狀況下運行redis-benchmark，那麼redis-benchmark將使用50個客戶端來進行性能測試，可是爲了在redis-benchmark和咱們本身的客戶端之間進行性能對比，讓redis-benchmark只使用一個客戶端要比使用多個客戶端更方一些。

在考察redis-benchmark的輸出結果時，切記不要將輸出結果看作是用於程序的實際性能，這是由於redis-benchmark不會處理執行命令所得到的命令回覆，因此它節約了大量用於對命令回覆進行語法分析的時間。在通常狀況下，對於只使用單個客戶端的redis-benchmark來講，根據被調用命令的複雜度，一個不使用流水線的Python客戶端的性能大概只有redis-benchmark所示性能的50%~60%。

另外一方面，若是你發現本身客戶端的性能只有redis-benchmark所示性能的25%~30%，或者客戶端向你返回了」Cannot assign requested address「(沒法分配指定的地址)錯誤，那麼你多是不當心在每次發送命令時都建立了新的鏈接。

下表列出了只使用單個客戶端的redis-benchmark與Python客戶端之間的性能對比結果，並介紹了一些常見的形成客戶端性能底下或者出錯的緣由：

比較了Redis在一般狀況下的性能表現以及redis-benchmark使用單客戶端進行測試時的結果，並說明了一些可能引發性能問題的緣由

性能或者錯誤	可能的緣由	解決方法
單個客戶端的性能達到redis-benchmark的50%~60%	這是不使用流水線的預期性能無	無
單個客戶端的性能達到redis-benchmark的25%~30%	對於每一個命令或者每組命令都建立了新的鏈接	重用已有的Redis鏈接
客戶端返回錯誤：」Cannot assign requested address「(沒法分配指定的地址)	對於每一個命令或者每組命令都建立了新的鏈接	重用已有的Redis鏈接

儘管上表列出的性能問題以及問題的解決方法都很是簡短，但絕大部分常見的性能問題都是由表格中列出的緣由引發的（另外一個引發性能問題的緣由是以不正確的方式使用Redis的數據結構）。若是讀者遇到了難以解決的性能問題，或者遇到上表沒有介紹的性能問題，那麼讀者能夠考慮經過1.4節介紹的方法來尋求幫助。

大部分Redis客戶端庫都提供了某種級別的內置鏈接池。以Python的Redis客戶端爲例，對於每一個Redis服務器，用戶只須要建立一個redis.Redis()對象，該對象就會按需建立鏈接、重用已有的鏈接並關閉超時的鏈接（在使用多個數據庫的狀況下，即便客戶端只鏈接了一個Redis服務器，它也須要爲每個被使用的數據庫建立一個鏈接），而且Python客戶端的鏈接池還能夠安全地應用於多線程環境和多進程環境。

上一篇文章： Python--Redis實戰：第四章：數據安全與性能保障：第7節：非事務型流水線
下一篇文章： Python--Redis實戰：第五章：使用Redis構建支持程序：第1節：使用Redis來記錄日誌