摘要:上一篇文章實戰第四章數據安全與性能保障第節非事務型流水線下一篇文章實戰第五章使用構建支持程序第節使用來記錄日志
上一篇文章: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來記錄日志
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/42639.html
摘要:為了讓讀者做好使用構建真實軟件的準備,本章將展示維護數據安全以及應對系統故障的方法。上一篇文章實戰第三章命令第七節其他命令下一篇文章實戰第四章數據安全與性能保障第節快照持久化 上一篇文章:Python--Redis實戰:第三章:Redis命令:第七節:其他命令下一篇文章:Python--Redis實戰:第四章:數據安全與性能保障:第2節:快照持久化 前面的幾章介紹了各式各樣的Redi...
摘要:上一篇文章實戰第四章數據安全與性能保障第節持久化下一篇文章實戰第四章數據安全與性能保障第節處理系統故障對于有擴展平臺以適應更高負載經驗的工程師和管理員來說,復制是不可或缺的。 上一篇文章:Python--Redis實戰:第四章:數據安全與性能保障:第3節:AOF持久化下一篇文章:Python--Redis實戰:第四章:數據安全與性能保障:第5節:處理系統故障 對于有擴展平臺以適應更高...
閱讀 3457·2021-11-17 17:00
閱讀 3818·2021-08-09 13:46
閱讀 2866·2019-08-30 15:54
閱讀 627·2019-08-30 13:54
閱讀 2945·2019-08-29 17:13
閱讀 3218·2019-08-29 14:00
閱讀 2975·2019-08-29 11:11
閱讀 1379·2019-08-26 10:15