測算Redis處理實際生產請求的QPS TPS

2021-08-13 04:40:43 字數 2123 閱讀 9227

redis發布版本中自帶了redis-benchmark效能測試工具;

示例: 

使用50個併發連線,發出100000個請求,每個請求的資料為2kb, 

測試host為127.0.0.1 埠為6379的redis伺服器效能:

./redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -d 2

...*****= sadd *****=

100000 requests completed in 2.27 seconds

500 parallel clients

3 bytes payload

keep alive: 1

4.66% <= 1 milliseconds

14.15% <= 2 milliseconds

23.87% <= 3 milliseconds

33.59% <= 4 milliseconds

43.13% <= 5 milliseconds

52.69% <= 6 milliseconds

62.08% <= 7 milliseconds

71.43% <= 8 milliseconds

80.66% <= 9 milliseconds

89.10% <= 10 milliseconds

95.23% <= 11 milliseconds

98.76% <= 12 milliseconds

99.59% <= 13 milliseconds

99.78% <= 14 milliseconds

99.87% <= 15 milliseconds

99.95% <= 16 milliseconds

99.99% <= 17 milliseconds

100.00% <= 17 milliseconds

44150.11 requests per second

我們關注結果最後一行:每秒44150.11個請求,既qps4.4萬; 

但這裡的資料都只是測試資料,測出來的qps不能代表實際生產的處理能力;

在實際生產中,我們需要關心這個指標,在我們的應用場景中, 

redis能夠處理的最大的(qps/tps)是多少?

測量redis qps的方式有兩種:

估計生產的報文大小,使用benchmark工具指定-d資料塊大小來模擬;

使用redis-cli中info統計資訊計算差值; 

redis-cli的info命令中有一項total_commands_processed表示:從啟動到現在處理的所有命令總數,可以通過統計兩次info指令間的差值來計算qps:

//返回redis-cli info中total_commands_processed的結果 

long getcmdprocessnum(rediscontext *c)

cout << "[err] not found total_commands_processed" << endl;

return 0;

}

程式實現很簡單,就不全貼在這裡了,完整**詳見github: 

在實際生產中,執行這個程式來統計實際的qps。 

執行示例:

time: 1 process:40962 tps:40839.48

time: 1 process:43741 tps:43610.17

time: 1 process:38935 tps:38779.88

time: 1 process:31724 tps:31597.61

time: 1 process:32169 tps:32008.96

time: 1 process:31634 tps:31476.62

time: 1 process:46007 tps:45823.71

time: 1 process:50460 tps:50258.96

time: 1 process:47309 tps:47167.50

time: 1 process:50511 tps:50359.92

...

測算Redis處理實際生產請求的QPS TPS

redis發布版本中自帶了redis benchmark效能測試工具 示例 使用50個併發連線,發出100000個請求,每個請求的資料為2kb,測試host為127.0.0.1 埠為6379的redis伺服器效能 在實際生產中,我們需要關心這個指標,在我們的應用場景中,redis能夠處理的最大的 q...

Redis 生產事件排查

日誌告警 oom command not allowed when used memory 大綱 設定maxmemory和相對應的 策略演算法,設定最好為物理記憶體的3 4,或者比例更小,因為redis複製資料等其他服務時,也是需要快取的。以防快取資料過大致使redis崩潰,造成系統出錯不可用。通過...

redis鎖的實際應用

以前對redis上鎖概念一直不太清楚,現在來整理下 其實就是當你的一次操作要保證資料的原子性和一致性,你需要先加個鎖 這個加鎖的動作其實也包含了驗證是否上鎖 然後進行操作,完了即使沒有成功也要解鎖,這個redis的操作為什麼要用lua語句因為要保證原子操作 解鎖的原則 在乙個使用者下 如下示例 lo...