メッセージポンプ（OnMessage）がMaxDeliveryCountExceededを発生させますか？

Question

私は、推奨に従ってAzureワーカーロールでMessage Pumpパターンを実装しました。現在、AutoComplete = TrueとMaxConcurrentCalls = 1で構成されています。

負荷テストを実行する際に、十分なVMインスタンスを準備して待機している限り、メッセージは正常に処理されます。あまりにも多くのメッセージをあまりにも少ないVMインスタンスに送ると、すぐにMaxDeliveryCountExceededの理由でメッセージの大部分（40％以上）がDLQに送信されます。

これは私の期待に反しています。メッセージが待ち行列に戻ってきて、VMインスタンスがゆっくりと噛んでも、最終的にはそれを処理すると思います。実際、メッセージキューのパターンを選んだ理由です。

私は、メッセージポンプが原因だと思っています。これらのメッセージを非常に迅速かつ激怒させようとしている舞台裏では、VMは追いつくことができませんが、その間に配信カウンタが増分されているため、数秒で10回の試行が行われ、 DLQ。

誰もがこの仕事をするための同様の経験または指針を持っていますか？

ありがとうございます。

Answer 1

に注意すべき点がいくつかあります：

1. あなたの処理は、キュー（またはサブスクリプション）で定義されたLockDuration期間よりも長くかかります。下位層の仮想マシンのIOPSも低くなるため、状況に影響を与える可能性があります。 MaxDeliveryCount（デフォルトでは10）と組み合わせると、DLQメッセージとなります。
2. PrefetchCountが有効になっており、1つのメッセージを受信するとバッチが取得されます。あなたの処理はいくつかのメッセージを通してしか得られないので、残りのバッチロックは失われ、メッセージは再配送されます。デフォルトでは、このプリフェッチは0（無効）に設定されていますが、使用されている場合もあります。

いずれにしても、DeliveryCountが増加し、最終的にDLQにメッセージが表示されます。