moxi で設定可能なコマンドライン フラグのいくつか (concurrency、downstream_max、downstream_conn_max、downstream_timeout、wait_queue_timeout など) を理解するには、moxi を介して要求に従うと役立ちます...
moxi の通常のデータの流れは次のとおりです。
クライアントが接続します
クライアントは moxi への接続 (アップストリーム conn) を作成します。moxi の -c コマンドライン パラメータは、最終的に最大接続数の制限を制御します。
この -c パラメータでは、moxi は memcached と同じ動作を継承し、既存の接続が閉じられるまでクライアント接続の accept() を停止します。既存の接続数が -c で定義されたレベルを下回ると、moxi はより多くのクライアント接続を受け入れます。
クライアントが要求を行い、待機キューに入れられます
次に、クライアントは単純な単一キー コマンド (set、add、append、単一キー get など) などの要求を行います。
この時点で、moxi はアップストリーム conn を待機キューの末尾に配置します。moxi の wait_queue_timeout パラメータは、moxi がタイムアウトして SERVER_ERROR 応答でクライアントに応答する前に、アップストリーム conn が待機キューに留まる時間を制御します。
同時実行パラメータ
次に、moxi が待機キューの先頭から同時に処理するアップストリーム conn リクエストの数に対する構成可能な最大制限があります。この構成可能な制限は、同時実行と呼ばれます。(これは以前は、おそらく紛らわしいことですが、downstream_max として知られていました。下位互換性のために、concurrency およびdownstream_max 構成フラグは同義語として扱われます。)
同時実行の構成は、スレッドごとおよびバケットごとです。つまり、moxi プロセス レベルの同時実行数は、実際には同時実行数 X num-worker-threads X num-buckets です。
デフォルトの同時実行設定値は 1024 です。これは、moxi が待機キューの先頭から 1024 個のアップストリーム接続要求を同時に処理することを意味します。(ただし、moxi が実際にリクエストを転送する前に、moxi にはさらに多くのキューがあります。これについては、後のセクションで説明します。)
1024 の同時実行値を例に取ると、4 つのワーカー スレッド (moxi の -t パラメータによって制御されるデフォルト) と 1 つのバケット (「デフォルト」バケットなど、ほとんどの人が最初に使用するもの) がある場合、その単一の moxi プロセスで同時に処理されるクライアント要求は 1024 x 4 x 1 または 4096 に制限されています。
moxi の構成で同時実行数が 1024 に増加した理由 (以前ははるかに低かった) は、moxi の設計の進化によるものです。もともと moxi には、唯一の内部キューとして待機キューしかありませんでした。moxi の歴史の中で、より多くの後期キューが追加されたので、待機キューからリクエストをより早く取得し、後期キューに入れる方が良い方法であることがわかりました。これらの後期キューについては、以下で説明します。
次に、クライアント要求がダウンストリーム接続にどのように一致するかについて説明しましょう。
キーハッシュ
同時に処理されるクライアント リクエスト (待機キューの先頭から取得) は、Couchbase サーバーへのダウンストリーム接続と照合する必要があります。クライアントのリクエストにキー (SET、DELETE、ADD、INCR、単一キー GET など) が含まれている場合、リクエストのキーはハッシュされて、適切なダウンストリーム サーバーの "host:port:bucket" 情報が検索されます。たとえば、「memcache1:11211:default」のようなものです。クライアントの要求がブロードキャスト スタイルのコマンド (FLUSH_ALL やマルチキー GET など) であった場合、moxi は取得する必要があるダウンストリーム接続を認識します。
ダウンストリーム conn プール
次に、適切なダウンストリーム conn を取得または予約するために、それらの host:port:bucket 識別子を使用してダウンストリーム conn プールへのルックアップがあります。スレッドごとにダウンストリーム conn プールがあります。各ダウンストリーム conn プールは、利用可能なダウンストリーム conn のリンクされたリストのハッシュ値を持つ、host:port:bucket によってキー付けされた単なるハッシュマップです。ダウンストリームconnリンクリストの最大長は、moxiのdownstream_conn_max構成パラメータによって制御されます。
downstream_conn_max パラメーター
デフォルトでは、downstream_conn_max 値は 4 です。値 0 は制限がないことを意味します。
したがって、downstream_conn_max を 4 に設定し、4 つのワーカー スレッドを持ち、1 つのバケットを持っている場合、moxi は任意の Couchbase サーバーに対して最大 4 X 4 X 1 または 16 の接続を作成するはずです。
ダウンストリーム サーバーへの接続
利用可能なダウンストリーム conn がなく、downstream_conn_max に達していない場合、moxi は、必要に応じて connect() および SASL 認証を実行することにより、必要に応じてダウンストリーム conn を作成します。
connect_timeout および auth_timeout パラメーター
connect() および SASL 認証には、connect_timeout および auth_timeout と呼ばれる独自の設定可能なタイムアウト パラメータがあり、これらはミリ秒単位です。connect_timeout のデフォルト値は 400 ミリ秒で、auth_timeout のデフォルト値は 100 ミリ秒です。
ダウンストリーム conn キュー
downstream_conn_max に達した場合、要求はダウンストリーム conn が使用可能になるまで待機する必要があります。したがって、要求は、ダウンストリーム conn キューと呼ばれる、スレッドごと、host:port:bucket ごとのキューに置かれます。ダウンストリーム conn がリリースされてダウンストリーム conn プールに戻されると、それらはダウンストリーム conn キューで待機しているすべての要求に割り当てられます。
downstream_conn_queue_timeout パラメーター
別の構成可能なタイムアウト、downstream_conn_queue_timeout があります。これは、タイムアウトになるまでに要求がダウンストリーム conn キューに留まる時間をミリ秒単位で定義します。デフォルトでは、downstream_conn_queue_timeout は 200 ミリ秒です。値 0 は、タイムアウトがないことを示します。
ダウンストリーム接続が予約されています
最後に、この時点で、ダウンストリーム conn がクライアントの要求に一致します。タイミング ヒストグラム統計を追跡するように moxi を設定した場合、moxi はリクエストの正式な開始時刻を取得します。moxi は、要求メッセージ バイトを下流の conn に非同期的に送信し始め、非同期的に応答を待ちます。
タイミング ヒストグラム統計をオンにするには、「time_stats=1」構成フラグを使用します。デフォルトでは、time_stats は 0 またはオフです。
downstream_timeout パラメーター
次に、downstream_timeout を設定した場合、moxi はリクエストのタイマーを開始します。moxi は、この時点でリクエストの処理に費やす時間を制限できます。タイマーが起動すると、moxi は「SERVER_ERROR プロキシ ダウンストリーム タイムアウト」をクライアントに返します。
downstream_timeout のデフォルト値は 5000 ミリ秒です。moxi がこの時間が経過したことを確認すると、リクエストに割り当てられたすべてのダウンストリーム接続を閉じます。タイムアウト時にダウンストリーム接続を閉じるという単純な動作のため、downstream_timeout を非常に短くすることはお勧めしません。これにより、接続の作成、タイムアウト、終了、再接続の繰り返しを回避できます。過負荷のクラスタでは、moxi がすでに過負荷になっているクラスタのダウンストリーム接続を常にタイムアウトにしないようにするため、またはサーバーが古い閉じられた接続でリクエストを処理しようとしているときにさらに新しい接続を作成することによって、downstream_timeout を増やしたい場合があります。サーバーが大幅に急増している場合は、この調整を検討する必要があります。
応答が受信されます
要求に対するすべての応答がダウンストリーム サーバーから受信されると (またはダウンストリーム conn にエラーが発生した場合)、moxi はそれらの応答をクライアントのアップストリーム conn に非同期的に送信します。タイミング ヒストグラム統計を追跡するように moxi を設定した場合、moxi はリクエストの正式な終了時間を追跡するようになりました。ダウンストリーム conn は、スレッドごとのダウンストリーム conn プールに解放され、別の待機中のクライアント要求 (存在する場合) がダウンストリーム conn キューから取り出され、そのダウンストリーム conn を使用するように割り当てられます。
バックオフ/ブラックリスト
ステップ 6 で、connect() の試行が失敗する場合があります。Moxi は、ダウンストリーム サーバーの connect() 失敗の数をカウントするように設定でき、最後に失敗した connect() 試行の時刻も追跡します。
connect() の失敗カウントを使用すると、connect_max_errors 構成パラメーターで定義されている connect() の失敗が多すぎる場合にサーバーをブラックリストに登録するように moxi を構成できます。connect_max_errors を超える数の connect() 失敗が見られる場合、moxi は、構成された時間の間、そのサーバーへの connect() 試行 (またはバックオフ) を一時的に停止するように構成できます。バックオフ時間は、connect_retry_interval 設定でミリ秒単位で定義されます。
connect_max_errors のデフォルトは 5 で、connect_retry_interval は 30000 ミリ秒、つまり 30 秒です。
connect_max_errors パラメーターを使用する場合は、downstream_conn_max 構成パラメーターよりも大きく設定する必要があります。