一.測試背景與目標
瞭解Redis和memcached在高並發條件下的回應時間、輸送量情況,以及對於伺服器的壓力情況(包括CPU、IO、網路);考察目前的memcached儲存timeline的方式的在高並發條件下的回應時間、輸送量、負載情況,以及使用redis儲存timeline的優勢
二.測試環境
1.伺服器
buzz090,刀片伺服器
2.作業系統
CentOS release 5.5系統,核心版本:Linux version 2.6.18-194.el5
3.硬體
Intel(R) Xeon(R) CPU E5640 @ 2.67GHz 16CPU;48G記憶體;千兆網卡
4.軟體:
uRedis版本:2.6.0-rc5(2.5.11),主要為了以後測試lua script功能,部署三個節點,每個節點開2G記憶體,共6G。開啟AOF,策略every second;關閉RDB;開啟lru,策略:allkeys-lru
uMemcached版本:1.4.5. 部署三個節點,每個節點開2G記憶體,共6G
5.用戶端
buzz097,硬體環境、作業系統和buzz090一致。
用戶端和伺服器使用內網互聯。
三.測試載入器
1.Redis用戶端
jedis,版本號碼2.1.0. 池設定使用預設,未調優。逾時時間為5s
2.Memcached用戶端
xmemcached,版本號碼1.3.5,使用一致性hash,使用BinaryCommandFactory,使用failure mode,不過未配置備機(-_-).逾時時間為5s
3.壓力測試工具
海波寫的壓力測試架構(strike)
四.測試方法
1.測試方法
分別以100、200、500、1000個並發線程壓力測試redis、memcached的方法,已耗用時間為20-60分鐘不等,每輪壓力測試取樣3000次,壓力測試中觀察如下參數:
u單次操作的回應時間
u3000次操作的回應時間(輸送量)
uCPU情況
u網路rx、tx
uIO
2.壓力測試的方法
Redis:set、zadd、evalSha
Memcached:set、(gets、cas的操作組合)
3.一些說明
對於讀操作做了少量測試,發現效能與set操作類似,就不做單獨的測試報告了。讀操作重要的一點是:在redis中,對於一個很大的sorted set,使用zrange時一定要指定範圍,否則將得到大量的錯誤
五.測試案例:
1.Redis的set方法和memcached的set方法比較
u測試方法:使用java產生的偽隨機數不斷的對redis進行set操作,對memcached做set操作。
u測試結果:
Redis:
100個線程下,單次操作時間為0-1ms;運行3000次的時間為80-95ms,即輸送量為32000-38000;CPU idle 96%;IO wr_sec/s為4000;網路rxKB/s:3000,txKb/s為1500-2000
200個線程下,單次操作時間0-1ms;運行3000次的時間為87-105ms,即輸送量為28500-34500;CPU idle 96%;IO wr_sec/s為4000;網路rxKB/s:3000,txKb/s為1500-2000
500個線程下,單次操作時間0-1ms;運行3000次的時間為95-110ms,即輸送量為27000-31500;CPU idle 96%;IO wr_sec/s為4000;網路rxKB/s:3000,txKb/s為1500-2000
1000個線程下,單次操作時間0-1ms;運行3000次的時間為97-120ms,即輸送量為25000-30000;CPU idle 96%;IO wr_sec/s為4000;網路rxKB/s:3000,txKb/s為1500-2000
Memcached:
100、200、500個線程下,基本相差不大:單次操作時間;運行3000次的時間為65-85ms,即輸送量為35000-46000;CPU idle 97%;IO wr_sec/s為260-350;網路rxKB/s:3000,txKb/s為3000
u小結
Memcached在小資料的寫入方面效能要優於redis的,不僅輸送量大,而且在伺服器的負載、IO方面都有明顯的優勢。
Redis的關閉AOF後,效能大概上升了5%-10%,值得使用。
Redis在lru的時候感覺不到效能上的損耗
2.Redis的zadd方法和memcached的gets cas方法組合的比較:
u背景:目前微博的timeline使用memcached的gets cas組合的方式,實現樂觀鎖,保證timeline的一致性。
u測試方法:為redis構建37個sorted set,為memcached構建3700個key,並發的寫入。其中redis