次の方法で共有

関連付けられたメッセージの制限を回避する方法

  • [アーティクル]

受信場所やオーケストレーションなどを介して BizTalk Server のキューに入れられたメッセージは、次のいずれかの方法で処理されます。

  • サブスクライバー (オーケストレーションまたは送信ポート) の新しいインスタンスがアクティブ化されます。

  • 関連付けによって、既存のサブスクライバー インスタンスにルーティングされます。 相関関係の詳細については、「 オーケストレーションでの関連付けの使用」を参照してください。

    開発者の多くは、ソリューションの受信場所で、ソリューションのアクティベーション メッセージと関連付けられたメッセージの両方が同じポートを通じて受信されると考えています。 メッセージ送信者が追跡する必要のあるアドレスの数が最小限に抑えられるため、このように考えるのが自然です。 ただし、BizTalk Serverの調整では、調整に関しては、アクティブ化メッセージのストリームと相関メッセージのストリームを個別に検討する利点があります。

    アクティベーション メッセージと関連付けられたメッセージの両方を同一の受信場所で受信すると、制限の状態も同じになります。これは、制限がホスト レベルで適用されるためです。 その結果、そのホスト内の受信場所で受信するすべてのメッセージは、1 つの単位として制限を適用されます。 多くの場合は問題となりませんが、関連付けとアクティベーションに制限を適用すると一種のシステム デッドロックが発生する場合もあります。

例

たとえば、オーケストレーションで 1 つのアクティベーションを受信し、これを使用して関連付けセットを初期化した後、引き続き 10 個の追加メッセージのコンボイを受信するとします。 さらに、負荷状況下で、アクティベーション メッセージと関連付けられたメッセージの両方を受信するにつれてバックログがスプールに蓄積され、その結果、受信可能なメッセージ容量に制限が適用されたとします。 あいにく、関連付けられたメッセージがアクティベーションと共に制限されるため、オーケストレーションの実行速度が低下し、さらなるバックログの増加と制限の追加を招きます。 このまま続行すると、システムのスループットがゼロに近づくまで制限が適用されます。

1 つの受信場所をアクティベーション用と関連付け用の 2 つに分割し、それぞれを別のホスト内に構成することによって、アクティベーション用のデータベース サイズの制限しきい値を、関連付け用のしきい値よりも低くできます。その結果、バックログの全体量が減少し、メッセージが正常に流れるようになります。

そのため、"単一受信場所のデータベース サイズのしきい値を上げて問題を解決できないのはなぜですか?答えは可能ですが、常に目的の動作が発生するとは限りません。 制限の主な役割は、システムの負荷が限界を超えないよう保護することです。 しきい値を上げすぎたり、完全にオフにした場合、システムを保護できなくなります。

推奨

上記のような、関連付けられたメッセージの制限が影響するシナリオでは、受信場所を個別のホストに分離し、それぞれ独自の制限を適用できるようにすることをお勧めします。

受信場所を個別のホストに構成したら、受信場所によって使用されるホストのデータベース サイズの制限しきい値を、オーケストレーションまたは関連付けによって使用されるホストのデータベース サイズの制限しきい値よりも低く設定します。

システムの負荷が、維持可能な最大スループット (MST) を超えることがないとわかっている場合や、スループットのピークがピーク イベントの合間に回復可能であるとわかっている場合は、制限のしきい値を上げる方法も効果があります。しかし、アクティベーションと関連付けに個別のホストを使用する方法ほど、高いスループットが維持されるとは限りません。