BizTalk：接続の数をWCFサービスに制限する方法は？

Question

たくさんのメッセージを含むファイルを入力として受信するBizTalkアプリケーションを開発しました。 BizTalk XML Resassemblerコンポーネントを使用して、Sepereateメッセージのファイルを「デバッチ」します。これらの各メッセージは、メッセージを変換してWCFサービスを呼び出すオーケストレーションによってメッセージボックスからピックアップされます。

私が今経験している問題は、各バッチに1000のメッセージが含まれており、これらの1000のメッセージがすべてWCFサービスを一度に呼び出すように見えることです。 WCFサービスはこれらのメッセージによって「爆撃」され、並行して10のメッセージのみを処理するように構成されています（各呼び出しはデータを処理してデータベースにデータを配置する必要があります）。 1分後に接続を再度再試行するようにWCFアダプターを構成しました。

最終結果は、BizTalkが最初にメッセージを吹き飛ばし、次に1000のメッセージすべてでWCFサービスを爆撃し、「忙しすぎる」例外を獲得し、何もしないで待って、1分が通過するまで待ってから、再び爆弾を爆撃します。の上。

BizTalkをその特定のWCFサービスに最大10の接続を開くように構成できれば、処理ははるかに効率的になりますが、私の知る限り、これは不可能です。 （WCFサービスは、net.tcpを使用するように構成されています。）

私はすでにいくつかの異なる方法でホストのスロットリング設定を試していましたが、それが役に立たないか、アプリケーションを耐え難いほど遅くしています。また、Biztalkでのスロットリングは、最初にサービスを爆撃し、爆撃していることに気づき、しばらく何もしないことに気づき、スロットルを持ち上げて再び爆撃を開始するように実装されているようです。リクエスト/メッセージをだまして、時間内にはるかに均等に広がる方がはるかに良いようです。たとえば、最大4メッセージを受信するようにWCFアダプターを構成したいと思います。現在可能なスロットルは、5秒のスライドウィンドウの上に、20以上のメッセージがある場合はスロットリングをアクティブにしたいと思っています。しかし、それは同じではありません。なぜなら、それは「バースト」効果を可能にするからです。

スループットを改善する方法はありますか？

Answer 1

この質問はすでに1年以上前のことですが、誰かが同じ問題を抱えている場合に備えて答えを追加したいだけです。

BizTalkホストのスロットリング構成で遊んでみました。これは助けにはなりませんでした。私は実際にシングルトンパターンを使用しようとはしませんでした。それは私が望んでいないものだからです。私たちはいくつかのメッセージを並行して簡単に処理できる強力なサービス指向アーキテクチャを作成しました。 。

それで、私はその時何をしましたか？最初に、実際に必要なものをもう一度検討しました。それぞれに1000のメッセージが含まれているファイルの束を処理する必要があります。ファイル内のメッセージが処理される順序は重要ではありません。ファイルが処理される順序は重要です。通常、最初のファイル1、次に2、3などを処理する必要があります。ただし、その厳格ではありません。順序はファイルの範囲にのみあります。たとえば、最初の範囲1〜5を処理する必要があり、次に6〜8の範囲ですが、範囲内でファイルの順序は重要ではありません。したがって、それらが要件でした。

私が最初に変更したのは、一度に1つのメッセージを処理する代わりに、サービスを変更してメッセージのコレクションを受け入れて、一度に1ファイルを処理できるようにすることです。一度に1つのファイルを処理することにより、WCFサービスへの1つの呼び出しのみがあります。これは、BiztalkとWCFサービスの間にはるかに少ないチットチャットがあるという利点があります。ただし、これにより、各メッセージを他のメッセージとは独立して処理する必要があるため、WCFサービス側のコードがより複雑になります（エラー処理がより複雑になります）。限られた数のファイルを一度に処理できた場合、忙しすぎるエラーを回避することもできます。

メッセージの実際の処理の横にあるWCFサービスは、ファイルの処理を「登録」するための呼び出しも提供します。これは、その時点でファイルを処理できるかどうかを確認するサーバー側のコードです。ファイルの順序を考慮し、前のファイル（範囲）が既にある場合にのみファイル（範囲）が登録できることを確認します処理。これらのレジスタコールは、内部で待機したループでファイル（範囲）を登録しようとします。コールはファイルを登録しようとしますが、それが受け入れられない場合は、待機してから再び試みます。私はこの解決策が本当に好きではありませんが、それは機能します。

そのため、ファイルの範囲の順序を考慮したソリューションが最終的にあり、その隣には並行して処理できるファイルの数に関する構成があります。これは、もう忙しいエラーが発生しないことを意味します。私のソリューションに完全に満足しているわけではありませんが、それは機能し、非常に安定しています。過去1年間、問題なく実行されてきました。

Answer 2

使用 Biztalk Singletonパターン. 。これは醜いです。しかし、BizTalkエレガントなアーキテクチャは、現実の世界に出会うときにugさを作り出します。

Answer 3

SOAP、HTTP、およびHTTPベースのWCFアダプターの場合、接続管理設定を使用して、そこに接続の数を制限できます。各BizTalkホストインスタンスが許可されている同時接続接続の数を正確に指定できます。SOAP、HTTP、およびHTTPベースのWCFアダプターの並行接続の設定

ノート：

1. これにより、あたりの接続数が制限されます ホストインスタンス. 。したがって、異なるホストに複数の送信ポートがある場合、またはホストごとに複数のホストインスタンスがある場合、作成された接続の総数はまだこの数を超える可能性があります。

2. これはだけです SOAP、HTTP、およびHTTPベースのWCFアダプター. 。 RVDGINSTEで記載されている他のWCFアダプター用ではありません

Answer 4

Biztalkのホストスロットリング状態は、Biztalk自体の入手可能性のための自己保存メカニズムです。これらを軽く変えません。

IgalのSingletonのアイデアと同様に、WSコールでアプリの過負荷を防ぐためにBizTalkに汚いことをすることができますが、最終的にこれを行うことでBiztalkサーバーのスケーラビリティを傷つける可能性があります。アプリケーションへの同期呼び出しが問題であると思われるでしょう - おそらくMSMQを使用してこれを非同期的に行うことに変わることを検討してください。

しかし、あなたが同期WCFを維持する場合、あなたも見ることができます これらのノブ 送信ホストのWCFアダプターの場合（まだWCF-Customアダプターに移動する必要があると思います）

Answer 5

私は使用しました インスタンスコントローラー 何度もパターンがあり、うまく機能しているようです。アイデアは、あなたがあなたの本当のメッセージをオーケストレーションのペイロードで包むことです。サービスを呼び出す時が来たら、あまりにも多くのオーケストレーションが実行されている場合は、脱水するオーケストレーションに渡します。そのシンプルな概念であり、うまく機能します。

ブログは非常に*時代遅れです。しかし、アイデアはうまくいきます。