Message Queue クライアントランタイムがメモリーなどのローカルリソースの上限に達する前に処理可能なペイロードメッセージの数には制限があります。この数に達すると、パフォーマンスに悪影響が出ます。したがって、Message Queue では、コンシューマあたりのメッセージ数または接続あたりのメッセージ数を制限できます。この制限は、接続を介して配信し、クライアントランタイムにバッファリングし、消費を待機できるメッセージの数を示しています。
クライアントランタイムへ配信されたペイロードメッセージの数が、いずれかのコンシューマの imqConsumerFlowLimit 値を超えた場合、そのコンシューマへのメッセージ配信は停止します。そのコンシューマの消費されないメッセージの数が、 imqConsumerFlowThreshold で設定された値を下回った場合にだけ、配信処理が再開されます。
次の例は、これらの制限の使い方を示しています。トピックコンシューマのデフォルト設定値を前提としています。
imqConsumerFlowLimit=1000 imqConsumerFlowThreshold=50
コンシューマが作成され、1000 のメッセージがあれば、ブローカはこれらのメッセージを最初のバッチとしてコンシューマに配信します。このとき一時停止はありません。1000 メッセージの送信後、ブローカはクライアントランタイムが追加のメッセージを要求するまで、配信を停止します。アプリケーションがこれらのメッセージを処理するまで、クライアントランタイムはそれらを保持します。その後、クライアントランタイムは、アプリケーションがメッセージバッファー容量の 50% (imqConsumerFlowThreshold) つまり 500 メッセージ以上を消費するのを待ってから、ブローカに次のバッチを送信するように要求します。
同じ状況で、しきい値が 10% の場合、クライアントランタイムは、アプリケーションが少なくとも 900 メッセージを消費してから、次のバッチを要求します。
次のバッチサイズの計算方法:
imqConsumerFlowLimit - (現在、バッファーに保留中のメッセージ数 )
そのため、imqConsumerFlowThreshold が 50% の場合、次のバッチサイズは、アプリケーションがメッセージを処理する速度に応じて 500 〜 1000 の間になります。
imqConsumerFlowThreshold がかなり高く (100% 近くに) 設定された場合、ブローカは比較的小さいサイズのバッチを送信するため、メッセージのスループットは低下することがあります。値が低過ぎる (0% に近い) 場合は、クライアントは次のセットを配信する前に残りのバッファリングされたメッセージの処理を完了してしまい、やはりメッセージスループットを低下させることがあります。一般に、パフォーマンスや信頼性に特定の問題がないかぎり、imqConsumerFlowThreshold 属性のデフォルト値を変更する必要はありません。
コンシューマベースのフロー制御、特に、imqConsumerFlowLimit は、クライアントランタイム内のメモリーを管理する最適な手段です。一般に、クライアントアプリケーションに応じて、接続でサポートする必要のあるコンシューマの数、メッセージのサイズ、クライアントランタイムで使用可能なメモリー総量がわかります。
一部のクライアントアプリケーションでは、エンドユーザーの選択によって、コンシューマの数が不確定な場合があります。そのような場合は、引き続き、接続レベルのフロー制限を使用してメモリーを管理できます。
接続レベルのフロー制御は、接続上のすべてのコンシューマについてバッファリングされたメッセージの合計数を制限します。この数が imqConnectionFlowLimit の値を超えると、合計数が接続の制限を下回るまで、接続経由のメッセージの配信は停止します。imqConnectionFlowLimit 属性は、imqConnectionFlowLimitEnabled を true に設定した場合にだけ使用できます。
1 つのセッションでキューに入るメッセージの数は、そのセッションを使用するメッセージコンシューマの数と、各コンシューマのメッセージ負荷によって決まります。クライアント側のメッセージの生成またはメッセージの消費に遅延が発生する場合は、通常は、アプリケーションを再設計し、より多くのセッションにメッセージプロデューサとメッセージコンシューマを分散し、またはより多くの接続にセッションを分散してパフォーマンスを改善できます。