圧力テストredis redis-benchmark最適化実践

3189 ワード

redisが開発し、メンテナンスで提供したredis-benchmarkmockテストに従って、圧力テストのシーンを記録します.
redis-benchmark基準試験redis-benchmark-h 127.0.0.1-p 6379-c 50-n 10000
  • は、戻るgetのタイプを例に、次の
  • の情報を返す.
  • では、10000回のget操作が実行する、0.27秒で完了し、各要求データ量は3サブセクションであり、79.44%の命令実行時間は1 ms未満であり、redisは、37037.04回のget要求
  • を毎秒処理することができる.
  • 印刷プロセス
  • を見たくない場合はredis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -q
  • シングルgetを操作してみました
  • key


  • ps:もう一つのいい圧力測定ツールabを見て、興味があれば見てもいいです.
  • 単一のredis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -q script load "redis.call('get','key1')"命令の操作を操作する応答時間は、keyを単独で操作する場合よりも遅いことがわかりました.getは、メモリ向けの操作が0.07s単位で計算される理由については、毎秒リフレッシュ率を参照してください.
  • 分析原因
  • redisにはデフォルトのリクエストバイト数があり、指定した単一のusを自分でテストするには手動key
  • が必要である.
  • まずクライアント自身でkey
  • に詰め込む.
  • mockは16個のサブセクションとして表すため、要求パラメータkey1
  • が加わる.
    前に操作した単一keyのテスト結果を比較してみましょう.
    応答時間がredis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t get -d 16より遅くなり,自分で計算ミスを犯したのではないかと疑い,0.01sと同じコマンドを試みた.mock自体のクエリーロジックの問題のように見えますが、redisドキュメントが表示されるまで、前の操作と次の操作の間の応答時間を許容できると考えられています.
  • 各クライアント(ベンチマークテストシミュレーション50クライアント、-cが別途指定されていない場合)は、前のコマンドの返信を受信したときにのみ次のコマンドを送信します.これは、サーバが各クライアントから各コマンドクライアント
  • を読み出すためにコールを読み出す必要があることを意味します.
    遅いクエリー分析(以下redis開発とメンテナンスの考え方)
  • redisクライアント実行コマンドフロー
  • 送信コマンド
  • コマンドキュー
  • コマンド実行
  • は結果
  • を返す.

    ps:スロークエリはステップ3の統計時間のみを行い、統計応答時間が長くないためredisliveで監視する必要があるredisはデフォルトのバルブ値を表し、各コマンドが遅いクエリーログ記録をトリガーする時間(ms単位)を意味します.slowlog-log-slower-than
  • slowlog-max-lenデータmock
  • さっきのredis-benchmark -c 50 -n 10000 -r 10000のデータと照らし合わせて、現在のデータ量
  • を見てみましょう.
  • 対応する構成項目
  • を設定する.
    ps:ここでは、ドキュメントの中で次のような構成の問題に注意する必要があります.
  • mockには、2つの構成を変更する方法があります.
  • プロファイル
  • の変更
  • redisコマンドを使用して、config setを構成するトリガ時間
  • に設定する.
  • 事故現場、プロファイルをロードした後、遅い照会条件
  • をトリガーしなかった.
  • linuxプロファイルのロードを表示するには、slowlog-log-slower-thanを環境変数として登録していたため、
  • は有効ではありません.
  • 生産環境でredisを使用するコマンド
  • は、次の
  • の遅いログを返します.
  • スロー・ログの各レコードの意味は次のとおりです.
  • 各スロー・ログ・エントリの一意の漸進識別子.
  • は、記録されたコマンドのUNIXタイムスタンプを処理する.
  • 実行に要する時間量は、マイクロ秒単位である.
  • は、コマンドパラメータの配列を構成する.


  • テストを始める前に、観測する指標を見てみましょう.
  • redisの健康指標
  • 生存状況
  • 接続数
  • ブロッククライアント数
  • メモリピーク
  • を使用
  • メモリフラグメント率
  • キャッシュヒット率
  • OPS
  • 持続化
  • 失効KEy
  • スローログ
  • このとき我々はredisのredis.confの占有が大きすぎることを避けるために,used_memoryで心拍包を遠隔で受けるとともに,redislivesarの性能
  • を観測すべきである.
  • 手動mock単一データ、ログの表示速度が遅いので、linuxredis操作コマンドを使用してみてください.
  • ロットpipline

  • Continue..QwQ