Azure Service Busは、キューまたはトピックへの同時接続の最大数を100に制限しているため、キュー/トピックにクエリを実行して、同時接続がいくつあるかを判断するために使用できる方法はありますか？
スロットリングイベントをキャプチャできることは承知していますが、システムに大きな負荷がかかっているときにキュー/トピックの数を積極的に増減できるアクティブなアプローチを強くお勧めします。
ここでの使用例は、応答メッセージを待機するプロセスです。応答は長時間実行されるプロセスからのものであり、サブスクリプションは相関フィルターを使用して、パブリッシャーとサブスクライバー間の双方向通信を容易にします。したがって、応答を待機するためにBeginReceive（）を実行する必要があり、そのような各パブリッシャーは待機時間の間接続を消費します。システムはすでに複数のトピック間で負荷を分散していますが、作成されるトピックの数を事前に把握して、頻繁に制限されないようにすると同時に、この目的のためにトピックが過剰にならないようにする方法が必要です。
リスナーの数を照会することは現在可能ではないと思います。サブスクライバー オブジェクトもそれを考慮していると思います。理論的には、トピックごとに最大 2000 のサブスクライバーがあり、それぞれが最大 100 の接続を許可する場合、それは多くの潜在的な接続です。サブスクライバーは協調的 (それぞれがすべてのメッセージのコピーを取得する) であり、サブスクライバーの受信者は競争的 (1 人だけがそれを取得する) であることを覚えておく必要があります。
また、1,000 人を超えるサブスクライバーを実行し始めるとパフォーマンスが低下するという未確認のレポートも見たので、必ずこのシナリオをテストしてください。
しかし...あなたのシナリオを考えると、パフォーマンス時間はおそらく最大の要因ではないと推測します(すでに長時間実行されているプロセスがあります)。したがって、ワークフローに数秒のラグを導入することは、おそらく重要ではありません。その場合は、BeginRecieve のタイムアウトをかなり短い時間 (数秒) に設定し、試行間にスリープ/待機の遅延を設けます。これにより、他のリスナーにもメッセージを受け取る機会が与えられます。また、複数のメッセージを受信し、それらを他のプロセスに割り当てて処理する方法 (この場合は連携?) を検討することもできます。
いくつかの考えを突き刺します。