1. リクエスト応答プロトコルと RTT:
Redis は、C/S モデルに基づく典型的な TCP サーバーです。クライアントとサーバー間の通信プロセスでは、通常、クライアントが最初にリクエストを開始し、サーバーはリクエストを受信した後に対応するタスクを実行し、最後に取得したデータまたは処理結果を応答の形式でクライアントに送信します。このプロセス中、クライアントはサーバーから返される結果をブロック方式で待機します。次のコマンド シーケンスを参照してください。
Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X Server: 3 Client: INCR X Server: 4
リクエストとレスポンスの各ペアのプロセスでは、ネットワーク送信によって生じる追加のオーバーヘッドを負担する必要があります。通常、このオーバーヘッドを RTT (ラウンド トリップ タイム) と呼びます。ここで、各リクエストとレスポンスの RTT が 250 ミリ秒であり、サーバーは 1 秒間に 100k データを処理できると仮定しますが、結果として、サーバーは 1 秒あたり最大 4 つのリクエストを処理できます。このパフォーマンスの問題を解決するには、どうすれば最適化できるでしょうか?
2. パイプライン:
Redis は、非常に初期のバージョンでコマンド パイプラインのサポートをすでに提供しています。具体的に説明する前に、誰もがより直感的に理解できるように、まず、上記の同期応答方式の例をコマンド パイプラインに基づく非同期応答方式に変換します。
Client: INCR X Client: INCR X Client: INCR X Client: INCR X Server: 1 Server: 2 Server: 3 Server: 4
上記の例からわかるように、コマンドを送信した後、クライアントはサーバーからの応答をすぐに待つ必要はなく、後続のコマンドを送信し続けることができます。コマンドが送信された後、以前のすべてのコマンドに対する応答が一度に読み取られます。これにより、同期モードでの RTT オーバーヘッドが節約されます。
最後に注意すべき点は、Redis サーバーがクライアントのリクエストがパイプラインベースであることを検出した場合、リクエストを受信して処理した後、サーバーは各コマンドの応答データをキューに保存し、それをクライアント。
3. ベンチマーク:
以下は、Redis 公式 Web サイトのテスト ケースとテスト結果です。このテストはループバック (127.0.0.1) に基づいているため、RTT にかかる時間は比較的短いことに注意してください。実際のネットワーク インターフェイスに基づいている場合、パイプライン メカニズムによってもたらされるパフォーマンスの向上はさらに大きくなります。重要な。
require 'rubygems' require 'redis' def bench(descr) start = Time.now yield puts "#{descr} #{Time.now-start} seconds" end def without_pipelining r = Redis.new 10000.times { r.ping } end def with_pipelining r = Redis.new r.pipelined { 10000.times { r.ping } } end bench("without pipelining") { without_pipelining } bench("with pipelining") { with_pipelining } //without pipelining 1.185238 seconds //with pipelining 0.250783 seconds
上記は Redis チュートリアル (13): パイプラインの詳細な説明の内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) をご覧ください。