Redisのパフォーマンス結果の分析

前回の記事では、Redisインスタンスが遅くなるのを防ぐためのトピックとアプローチについて説明しました。次に、測定の方法を検討します。 パフォーマンス。

何を測定するか

今回の記事では、コマンドのレイテンシとそのコンポーネントについて説明します。なんで？ Redisサーバー/ライブラリを介してプッシュできるコマンドの数は、各コマンドの速度の結果であるためです。

すばやく簡単：CLI

コマンドレイテンシを確認する最初の方法は、コマンドラインクライアントredis-cliを使用することです。 。すばやく、すぐにチェックポイントを開始できます。ここでの例では、簡単にするためにlocalhostを使用しますが、セットアップでは-h <host>を使用する必要があります。 オプションと必要に応じて-a <auth> および-p <port> 。

基本レイテンシ

基本的なレイテンシーの結果を取得するには、redis-cli –latencyを実行します。これにより、最小、最大、平均、および反復回数を示す一連の数値が出力されます。これらの反復は、開いている接続に対してRedisコマンドPINGを実行することで構成されます。したがって、サーバーに接続する時間は含まれていません。コードがすべてのコマンドに接続されている場合、このコマンドが示すよりもはるかにパフォーマンスが低下します。

このコマンドは、コマンドを強制終了するまで実行されます。CTRL-Cを使用すると簡単に実行できます。待ち時間の数値はミリ秒単位です。したがって、次の結果：

min: 0, max: 1, avg: 0.11 (11369 samples)

つまり、最小遅延は1ミリ秒未満、最大遅延は1ミリ秒で、PINGごとの平均遅延は0.11ミリ秒でした。はい、これはローカルホスト接続です。これらの数値は、11,369個の「サンプル」またはPINGコマンドから計算された結果です。

または、代わりに–latency-historyを使用することもできます。このオプションを使用すると、一時的なスライスに分割できます。 redis-cli –latency-historyを実行すると、デフォルトのウィンドウである15秒が使用されます。結果は次のようになります：

min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds range

–latencyと同様に、このコマンドは強制終了するまで実行されます。別の間隔で実行する場合は、-iを渡すことができます。例：

redis-cli --latency-history  -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range

これらの操作は単にPINGコマンドを使用するため、これはどのバージョンのRedisに対しても機能するはずです。

固有のレイテンシ

一見すると、この名前から、内部遅延モードがサーバーの固有の遅延を測定していると思われるかもしれません。そうではありません。 GitHubのredis-cliソースを見ると、サーバーとさえ通信していないことがわかります：

start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;

固有のレイテンシーモードに関するソースコメントによると：

システムコールの結果ではない実行中のプロセスの最大遅延を測定します。基本的に、このソフトウェアは、カーネルが実行の機会なしにプロセスを離れる時間についてのヒントを提供する必要があります。

これが行っているのは、クライアントホストでの固有のレイテンシをテストすることです 。これは、問題が実際にサーバー自体ではなくクライアント側にあるかどうかを知るのに役立ちます。

したがって、便利ではありますが、レイテンシをチェックする最初のステップにはおそらく含まれないはずです。 更新 ：Salvatoreと話した後、彼はサーバーからこのコマンドを実行する意図があることを確認しました。つまり、Redisサーバーへのシェルアクセスがある場合は便利ですが、それ以外の場合は役に立ちません。これは、Redisサービスプロバイダーを使用する場合によくあることです。

コミッサールの使用

Commissarは、Redisのレイテンシと全体的なパフォーマンスを追跡およびテストするために取り組んでいる小さなスイートです。警告：開発の初期段階であり、多くの変更が行われる可能性があります。このため、本番環境以外の品質のソフトウェアを快適に使用できる場合にのみ使用してください。コミッサールはGithubコミッサールリポジトリにあります。

特にこの記事では、レイテンシツール/ディレクトリについて説明します。

このツールは、環境変数を介して構成され、特定のRedisインスタンスに接続し、redis-cliと同じ「PINGコマンドの時間」メカニズムを実行します。テストのパリティを維持するためにこれを行いました。より多くの情報を出力し、（現在）MongoDBに保存する機能が異なる点は、今後さらに多くのストアが追加される予定です。

この記事が書かれてから出力が変更された可能性がありますが、レイテンシーの実行は次のようになります。

./latency 
Connected to <host:ip>

100000 iterations over 53698us, average 536us/operation

Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us

Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37us

この実行では、時間単位が「us」（つまりマイクロ秒）であることに注意してください。また、パーセンタイルブレイクアウトが得られることがわかります。これにより、単純な最小/最大/平均と比較して、レイテンシがどのように見えるかをより正確に把握できます。このコンテキストでは、「ジッター」はサンプルの標準偏差です。

この出力は、全体的にかなり見栄えが良いことを示しています。この特定の例は、プライベートネットワークを介したものです。ピークが平均よりもはるかに高いことがわかりますが、反復の95％は640マイクロ秒以下で発生します。これは私たちに何を伝えますか？

散発的なネットワークの問題、散発的なサーバー側の遅延、または出力に影響を与えるテストクライアントのガベージコントロールのようなものがあることを示している可能性があります。これが、リクエストの配信が利用可能になる理由です。つまり、「高い」結果がどれほど一般的であるかを確認できます。

問題がどこにあるかを判断するには、まずサーバー上のコマンドにかかる時間を確認する必要があります。これにより、サーバーに問題があるかどうかがわかります。

この場合、たとえば、Redis情報の出力を確認し、特にCommandstatsセクションを確認することをお勧めします。

redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68

ここでは、サーバーでPINGを実行する平均時間が0.68マイクロ秒であることがわかります。明らかに、pingコマンド自体が原因ではない可能性があります。ただし、テスト中に他のコマンドが実行され、Redisプロセスがバックアップされて遅延が発生した可能性があります。

レイテンシーツールに最近追加されたのは、同時レイテンシーテストを実行する機能です。 LATENCY_CLIENTCOUNTで環境変数を設定することにより、Redisサーバーへの複数の接続を実行し、同時実行性がレイテンシーの結果にどの程度影響するかを確認できます。たとえば、10個のクライアントと100個、さらには1000個の同時クライアントがある場合に単純なRedisPINGコマンドで見られる違いを確認できます。これは、開発/ステージングと本番環境で発生している可能性のある違いを確認するのに役立ちます。

コンテナからのテスト

Dockerコンテナーからテストを実行することをお勧めしますか？ここで、golatencyツールのみを含むビルド済みのDockerコンテナーをパブリックDockerレジストリーにプッシュします。 Docker Pull therealbill / golatencyを実行すると、画像が取得され、数秒で実行できるようになります（現在、画像サイズは4MB未満です）。

環境変数を指定してdockerrunを呼び出すだけで、ReadMeの指示に従って接続および構成できます。次に、stdoutから出力をプルするか、デーモンとして実行されている場合は、dockerログを介して出力をプルします。何もビルドする必要はありません。ツールに大幅な変更を加えるたびに、Dockerリポジトリが新しいイメージで更新されます。または、リポジトリにDockerfileがあり、必要に応じてカスタマイズできます。

最終的な考え

Redisを使用してパフォーマンスを分析するのは難しい場合があります。幸い、レイテンシとスループット、およびそれらがアプリケーションに与える影響を理解することで、Redis自体ではなく、アプリケーションでのRedisの使用の分析に集中できます。 Zen ofRedisの「パフォーマンスの鍵はRedisの速度を低下させない」というフレーズを念頭に置くことで、Redisの使用法と最適な使用方法の理解を深めると同時に、ネットワークの問題とデータ構造の代替案を分離することで、よりスマートで効率的なアプリケーションを作成します。 、結果としてパフォーマンスが向上します。