BizTalk 2010 で一度に実行できるオーケストレーションの最大数を設定しようとしています。ホスト レベルでオーケストレーションのスロットリングを指定でき、一時停止と再開を指定するオプションがあることがわかりました。仕様 (ホスト設定の「オーケストレーション調整」タブ)。
MSDN で見つけた限られたドキュメントを読んだことに基づいて、「一時停止」設定に指定された数で、BizTalk が「一時停止」し、アクティブなオーケストレーションの数が < = Resume at 設定の仕様。これは正確な解釈ですか？
このページを見てください。 BizTalk 設定ダッシュボード
特に、「一時停止」セクションには次のように書かれています。
サブスクリプションに保存するメッセージの最大数を指定します。サブスクリプションに、指定された数以上の消費待ちのメッセージがある場合、メッセージはサブスクリプション インスタンスに配信されません。メッセージの最小数は、「resume at」値になります。たとえば、Pause at の値を 100 に設定すると、オーケストレーションに 100 個の未処理のメッセージがあり、MessageBox が追加のメッセージの送信を停止することを意味します。
この設定についての私の理解 (BizTalk 2006 以降の BTSNTSvc.exe.config のThrottling PauseAt / ResumeAt エントリと同じであると仮定) は、メッセージの数を単一のサブスクリプション (ポートまたは任意のタイプのオーケストレーション) に制限することです。必ずしも特定のタイプの同時オーケストレーションの数ではありません。このサブスクリプションのそれ以降のメッセージは、メッセージ ボックスのキューに入れられます。(BTS スロットリング設定は、アプリ固有の調整メカニズムではなく、BizTalk の自己保存メカニズムであることがわかりました)
特定の種類のオーケストレーションの数を制限する必要がある場合 (たとえば、BizTalk が限られた WCF または SQL リソースでダウンストリーム アプリケーションをオーバーロードしている場合)、シングルトン オーケストレーションのバリアントを実装する必要があります (つまり、同時オーケストレーション <= N)。Richard Seroter は、そのようなメカニズムについてここで説明しています(ロード バランシング/ラウンド ロビン スケジューリング、ただし、コメントで Mike S によって提案された乱数生成の変更を使用しました)。単一のオーケストレーションがすべて/多数のメッセージを処理するため、シングルトンに関していくつかの追加の堅牢性に関する懸念があります。たとえば、メッセージと変数をできるだけ厳密にスコープします。また、メッセージのバックログが大きくなりすぎないように、シングルトンを監視する必要があります。シングルトンで 1 万件以上のメッセージがキューに入れられると、処理時間が遅くなることがわかりました。