4

一連のメッセージを含むファイルを入力として受け取るBizTalkアプリケーションを開発しました。BizTalk XML逆アセンブラコンポーネントを使用して、個別のメッセージでファイルを「デバッチ」します。これらの各メッセージは、メッセージを変換してwcfサービスを呼び出すオーケストレーションによってMessageBoxから取得されます。

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

その結果、BizTalkは最初にメッセージをデバッチし、次にwcfサービスを1000個のメッセージすべてで爆撃し、「ビジー状態」の例外を大量に取得し、何もしないで1分が経過するまで待機してから、もう一度爆撃します。の上。

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

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

スループットを向上させる方法はありますか？

4

5 に答える 5

3

BizTalkシングルトンパターンを使用します。これは醜いです。しかし、BizTalkのエレガントなアーキテクチャは、現実の世界と出会うと醜くなります。

于 2010-08-28T19:41:11.787 に答える
2

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

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

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

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

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

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

于 2011-11-06T12:20:54.873 に答える
2

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

ノート：

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

  2. これは、SOAP、HTTP、およびHTTPベースのWCFアダプター専用です。rvdginsteが指摘しているように、他のWCFアダプター用ではありません

于 2013-07-11T03:52:56.067 に答える
1

BizTalkのホストスロットリング状態は、BizTalk自体を利用できるようにするための自己保存メカニズムです。これらを軽く変更することはしません。

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

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

于 2010-08-29T11:42:44.213 に答える
0

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

私はブログが非常に*日付が付けられていると言います..しかし、アイデアはうまくいきます。

于 2010-08-31T20:10:54.800 に答える