NServiceBusタイムアウトディスパッチャキューにストレステスト中にメッセージがいっぱいになっています

Question

2回のタイムアウトを使用するサガでいくつかのストレステストを行っています。テスト中に約21Kのサガが作成されます。つまり、42Kのタイムアウトが発生することになりますが、MSMQの記憶域の上限に達したためクラッシュするまで、サガのタイムアウトディスパッチャのキューには何百ものメッセージが流入しています。

RavenDBからSQL Serverに永続化メカニズムを切り替えたので、この現象が見られました。

誰かが間違っている可能性があるアイデアはありますか？

交通：MSMQ
永続性：NHibernateの使用 パッケージ：

NHibernate version 4.0.4.4000 
NServiceBus version 5.2.14 
NServiceBus.Host version 6.0.0 
NServiceBus.Log4Net version 1.0.0 
NServiceBus.NHibernate version 6.2.7 

テストのセットアップ：
*エンドポイント1は2
*エンドポイント2つのホスト開始されサガをエンドポイントする22000件のメッセージを送信していますそのメッセージで
*各サガはイベントを発行した後、4分で1分、10分で1分の2つのタイムアウトを要求します。

観測された動作：
*エンドポイント1は22Kメッセージを1分以内に送信します。
*エンドポイント2（サガ）は、1秒あたり5~10メッセージを処理します。
* 4分後、最初のタイムアウトが発生しますが、エンドポイント2はキューからメッセージを処理しているため、まだ新しいサガインスタンスが作成されています。
*その瞬間から、sagaエンドポイントのタイムアウトディスパッチャキューはメッセージでいっぱいになっています。
* 10分後、timeoutsdispatcherキューにはすでに170,000を超えるメッセージが含まれており、まだいっぱいです。
*これは、MSMQストレージの制限に達するか、入力キューからのすべてのメッセージが処理されるため、エンドポイント2がクラッシュするまで続きます。後者が最初に発生すると、タイムアウトディスパッチャキューのメッセージ数は最終的に0に達するまで減少し始めます。

Answer 1

RavenDBで同じストレステストを実行しましたか？また、SQL Serverは、高速のドライブを使用して同等以上の強力なマシン上にありますか？あなたのサガ

• ため

  更新

  いくつかのチェックは、[ユニーク]属性が使用され、それが適切に使用されていますか？言い換えれば、受信メッセージごとに一意のIDを使用していますか？したがって、2つのタイムアウトを生成しているすべての着信メッセージは、独自のサガインスタンスを作成しますか？すべての着信メッセージが同じSagaにアクセスしている場合、これはスループットを極端に制限する素晴らしいケースです。サガ・インスタンスがすでに作成されているとしたら、説明は複雑になるはずです。そのため、Message1が入り、データベース内の行を見つけようとします。見つけてロックします。 2番目のメッセージは同時に入力され、行が見つかるがロックされています。再試行されます。 Message3が来るまでMessage3が入り（同時性が100に設定されている場合）、すべてが同じことをやろうとするとすぐに失敗します。あなたはしばらくの間スループットを制限することがわかります:)

• あなたのSagaテーブルとタイムアウトテーブルの正しいインデックスはありますか？
• 最大同時実行レベルはどのように設定されていますか？

メッセージの数に基づいて、22kメッセージを送信すると、44kタイムアウトメッセージが送信されます。画像これらのタイムアウトはすべてがMSMQにあります。メッセージが1Kbのように実際には本当に小さいと想像してみてください。 NServiceBusによって追加されたヘッダ情報は2Kbを占める可能性があります。それは44.000倍で、3Kbはおよそ135メガバイトです。したがって、既定で1GBのクォータを持つ既定のMSMQインストールを満たす方法はありません。

これはおそらく、デッドレターのキューが完全にいっぱいであることを意味します。 Find more information on MSMQ connectionstringsを開き、適切な接続文字列を設定します。例えばTimeToBeReceived属性設定（link）と

<connectionStrings> 
    <add name="NServiceBus/Transport" 
    connectionString="deadLetter=false;journal=false;"/> 
</connectionStrings> 

メッセージはdeadletterキューに終わります。また、キューをパージすると、すべてのメッセージがデッドレターキューに移動します。適切な接続文字列を設定しない限り。