壓力測試redis redis-benchmark 優化實踐

根據 redis開發與運維中提供的redis-benchmark的mock測試,記錄壓力測試的場景如下

redis-benchmark 基準測試 redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000

• 針對返回的 get型別為例,返回的資訊如下

• 上面執行了10000次get操作,在0.27秒完成,每個請求資料量是3個子節,79.44%的命令執行時間小於1ms,redis每秒可以處理37037.04次get請求
• 如果我們不想看其中的列印過程

redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -q

• 我們試著get操作單條 key
  • redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -q script load "redis.call('get','key1')"

ps:看到另外一個不錯的壓測工具ab，有興趣的話可以看看

• 我們發現操作單條key命令操作的響應時間會比之間我們單獨用get操作的時候,慢了 0.07s，至於為什麼面向記憶體的操作需要以us為單位計算，參考每秒重新整理率，當中提到這樣一句話

  *在硬碟上進行讀寫操作要比在記憶體上進行讀寫操作，時間上慢了近5個數量級，記憶體是0.1μs單位、而硬碟是10ms。*
  複製程式碼

• 分析原因
  • redis有預設的請求位元組數，如果要自己測試指定的單條key需要自己手動mock
  • 先在客戶端自己塞進key

• 因為 key1表示為16個子節，所以加入請求引數

  redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -d 16

對比一下之前操作單條key的測試結果

我們可以觀察到響應時長慢了0.01s,懷疑是不是自己計算出錯，嘗試 mock相同的命令

看來是 redis本身的查詢邏輯問題，暫時認為可以允許上一個操作和下一個操作之間的響應時間,直到看到了redis文件這句話

• 每個客戶端（基準測試模擬50個客戶端，如果沒有另外指定-c）僅在收到上一個命令的回覆時才傳送下一個命令，這意味著伺服器可能需要讀取呼叫才能從每個客戶端讀取每個命令客戶

針對慢查詢分析(以下為redis開發與運維的思路)

• redis 客戶端執行命令流程
  • 傳送命令
  • 命令排隊
  • 命令執行
  • 返回結果

ps: 慢查詢只對步驟3進行統計時間，因為不適合統計響應時長，需要用redislive監控

slowlog-log-slower-than代表預設閥值，意義為每條命令觸發慢查詢日誌記錄的時間(單位為ms)

slowlog-max-len

• mock資料 redis-benchmark -c 50 -n 10000 -r 10000

  • 對照剛剛mock的資料，檢視一下當前的資料量

• 設定對應的配置項

ps:這裡需要注意一個配置問題，在文件中原話如下：

• redis中有兩種修改配置的方法:
  • 修改配置檔案
  • 使用config set命令將 slowlog-log-slower-than設定為需要配置的觸發時間
• 事故現場,載入配置檔案後，沒有觸發慢查詢條件

• 檢視linux配置檔案載入,之前是把redis.conf作為一個環境變數註冊，因此沒有生效
• 使用redis在生產環境中的命令
  • 返回慢日誌如下

• 慢日誌每條記錄的意義如下:
  • 每個慢日誌條​​目的唯一漸進識別符號。
  • 處理記錄的命令的UNIX時間戳。
  • 執行所需的時間量，以微秒為單位。
  • 組成命令引數的陣列。

在開始測試之前，我們看一下需要觀測的指標

• redis的健康指標
  • 存活情況
  • 連線數
  • 阻塞客戶端數量
  • 使用記憶體峰值
  • 記憶體碎片率
  • 快取命中率
  • OPS
  • 持久化
  • 失效KEy
  • 慢日誌
• 此時我們為了避免redis的used_memory佔用過大，應該用 redislive遠端接受心跳包的同時，應該用sar觀測linux的效能
• 手動mock單條資料，並檢視日誌的速度有些慢，嘗試使用redis的pipline操作命令
  • 批量get

Continue..QwQ