「MDB スロットル」のさまざまな設定を調整して、 サーバーが所定時刻に処理する MDB 作業の量を制御することができます。
MDB スロットル・サポートは、各リスナー・ポートの現在処理されているメッセージ数のカウントを維持します。
処理中のカウントは、コントローラーが、 このリスナー・ポートの作業レコードが完了した (アプリケーションのトランザクションがコミットされたかどうかにかかわらず) という通知を受けるたびに、 1 ずつ減少します。 減少した後、処理中のカウントがこのリスナー・ポートの下限しきい値に照らし合わせて確認されます。 処理中のカウントが下限しきい値まで低下すると、以前にブロックされたキュー・エージェント・スレッドが喚起 (通知) されます。 その時点で、新規作業レコードを WLM キューに入れることができます。 これを、スロットルが「解放」されたといいます。
下限しきい値と上限しきい値は、リスナー・ポートの最大セッション数パラメーターという 1 つの設定で、 外部に設定されます。 上限しきい値は、内部では、外部で定義された最大セッション数と等しい値に設定されます。 下限しきい値は、内部では、次の公式によって計算および設定されます。 下限しきい値 = (上限しきい値 / 2) この場合、値は最も近い整数に切り捨てられます。
ただし、 メッセージ・リスナー・サービスがカスタム・プロパティー MDB.THROTTLE.THRESHOLD.LOW.EQUALS.HIGH (値は「true」に設定) を定義 して構成されている場合、下限しきい値は内部で上限しきい値 (外部で設定されたリスナー・ポートの最大セッション数プロパティー) に設定されます。
リスナー・ポートの「最大セッション数」値を、 スケーラブル・サーバー内のすべてのサーバントで使用可能なワーカー・スレッド数の 2 倍に設定 (2*WT) する ことが推奨される理由を考慮してください。 理由は、いずれかのサーバントに使用可能なワーカー・スレッドがある場合、MDB スロットルがブロックされているた めに、それをアイドル状態のままにするのは望ましくないからです。 つまり、WLM キューが空で、サーバントのワーカー・スレッドが使用可能で、さらにスロットルがブロック状態にあるのは好 ましい状態ではありません。
さらに、上限しきい値を 2*(WT+N) に設定することにより、 サーバントのワーカー・スレッドが空いてスロットルを解放したときに、 前処理されてディスパッチ可能な状態で WLM キューに入っている N 個のメッセージのバックログが存在することが確実 になります。 値が非常に高いと、WLM キューの過負荷という問題が起きます。 スロットルではこの問題が回避されますが、ここでは、推奨される特定の上限はありません。 (これらのチューニング考慮事項では、 キュー (またはトピック) が処理されるメッセージとともに完全にロードされていることが前提となります。)
したがって、上限しきい値を上げると、 ワークロードが急上昇した場合に、サーバーが作成する、 WLM キューに入っている前処理されたメッセージのバックログが小さくなります。 上限しきい値を上げることの欠点、つまり否定的な側面は、 所定のメッセージとともにアプリケーションをディスパッチする前に、 所定のメッセージの作業レコードがタイムアウトする可能性が高くなることです。 (つまり、サーバーが MDB タイムアウトの限度に達する可能性があります。) 所定のメッセージは最終的にサーバーに再送信されますが、 それは後のことなので、その時点までの処理が無駄になる場合があります。 また、上限しきい値が非常に高いと、MDB スロットル機能が迂回されます。 この場合、WLM キューは過負荷になる可能性があり、これはサーバー障害の原因となります。
スケーラブル・サーバーは、スループットを最大化するという目標で設計されていますが、 リスナー・ポート設定を使用して、ワークフロー管理の目標を達成することができます。
例えば、上限しきい値の設定を「1」にすると、 宛先で受信される順序でメッセージが処理されることが保証されます。
特定のリスナー・ポートの並行性の制限を、サーバーがサポートするよりもはるかに少なくするための、容 量や他の要素に基づいた、その他のビジネス上の理由もあります。 この構成は確かにサポートされていますが、 使用可能なアイドル状態のワーカー・スレッドがある場合、スロットルがブロックする原因になることがあります。
サーバーが、最大サーバー・インスタンスの値が 3 に設定され、ワークロード・プロファイルが IOBOUND に設定されて、構成されているとします。 2 つの CPU があるので、WebSphere Application Server は各サーバント内に 6 つのワーカー・スレッドを作成します。 アプリケーション (キューにマップされた単一の MDB) は、 各メッセージを比較的高速に処理します (タイムアウトのリスクを減らすため)。 所定のメッセージが MDB キューに到着してから、このメッセージの MDB ディスパッチ終了までの合計時間をで きるだけ短くします。
作業が増加した場合に応答時間を短くするには、 バックログを大きくするようにします。 リスナー・ポートの最大セッション数の値を 100 = 2 * (3 * 6 + 32) に設定します。