Azure Service Bus トピックを介して Web ロール パブリッシャーにサブスクライブする外部クライアントを含む pub/sub アプリケーションがあります。現在の請求サイクルでは、25,000 件を超えるメッセージを送受信したことが示されていますが、ダッシュボードでは、送信したメッセージが 100 件未満であることが示されています。差異を理解するために、実装を調査し、仮定を確認しています。
調査の一環として、クライアント マシン上のクライアント<=>サービス バス トラフィックの Wireshark キャプチャを収集しました。文書化されていない定期的な通信パターンに気付き、より深く理解したいと考えています。次の交換は、バス上でアクティビティがない場合に 50 秒ごとに 1 回発生します。
- クライアントは ~200B をサービス バスにプッシュします。
- 10 秒後、サービス バスは ~800B をクライアントにプッシュします。クライアントは、空のメッセージの受信を登録します (ブレークポイントによって決定されます)。
- クライアントはすぐに応答して、サービス バスに ~1000B をプッシュします。
関連情報:
- これは、Web ロールがアクティブにデータをサービス バスにプッシュしていない場合に発生します。
- Web ロールから正当なメッセージを受信すると、50 秒が完全に経過するまで上記のパターンは発生しません。
- クライアントとサーバーの両方が TCP 経由で sb:// namespace .servicebus.windows.net に接続します。
- アプリケーション メッセージは 64 KB 未満です
質問
- 私たちが見ている定期的な 3 パケットのメッセージ交換の原因は何ですか? それはある種のキープアライブですか？
- 3 つのパケットはそれぞれ、個別に請求可能なメッセージとしてカウントされますか?
- この動作は構成可能ですか、それとも文書化されていますか?
編集：
メッセージを受信するコードは次のとおりです。
private void Listen()
{
_subscriptionClient.ReceiveAsync().ContinueWith(MessageReceived);
}
private void MessageReceived(Task<BrokeredMessage> task)
{
if (task.Status != TaskStatus.Faulted && task.Result != null)
{
task.Result.CompleteAsync();
// Do some things...
}
Listen();
}