ユーザーがファイルをブロブ ストレージにアップロードしたときにトリガーされる WebJob があります。これは、アップロードが完了すると作成されるキュー ストレージ メッセージによってトリガーされます。
ファイルの目的に応じて、メッセージを他のキューに投稿して、処理ジョブをトリガーします。
これらのジョブの一部は時間が重要であり、比較的短時間で実行されます。あるケースでは、処理に約 3 秒かかり、ユーザーは結果を待っています。
ただし、キューの最小ポーリング間隔は 2 秒であるため、2 つの WebJob が呼び出されるまでユーザーが待機する必要がある時間は、通常、待機時間の 2 倍になります。
最初のハンドラーがキュー メッセージを送信すると、対応する処理ハンドラーがすぐにトリガーされることを期待して、2 つの Web ジョブを 1 つに結合しようとしましたが、実際には、メッセージを取得する前に一貫して 2 秒間待機します。
私の質問は、待機中のメッセージがあることがわかっている場合に、同じ Web ジョブ内からすぐにキュー トリガーをチェックするように Web ジョブに指示する方法はありますか? または、WebJob 内からキューに投稿した場合にキュー トリガーをすぐにチェックするように構成することをお勧めします。
または、サービス バス キューに切り替えると、新しいメッセージに対する応答性が向上しますか?
アップデート
Blob トリガーの使用に関するドキュメントでは、次のように述べています。
Blob 属性を使用して作成した BLOB には例外があります。WebJobs SDK が新しい BLOB を作成すると、一致する BlobTrigger 関数に新しい BLOB をすぐに渡します。したがって、blob の入力と出力のチェーンがある場合、SDK はそれらを効率的に処理できます。ただし、他の方法で作成または更新された BLOB に対して BLOB 処理関数を実行する際の待機時間を短くしたい場合は、BlobTrigger ではなく QueueTrigger を使用することをお勧めします。
ただし、キューに似たものについては言及されていません。つまり、このシナリオで非常に短い待ち時間が必要な場合は、キューよりもブロブの方が適していますが、これは間違っているようです。
更新 2
最終的に、オーケストレーション コードを最初の WebJob からアプリケーションのサービス レイヤーに引き出し、WebJob を削除することで、この問題を回避することになりました。これは、ファイルのアップロード後に WebJob の処理のみをトリガーする必要があることを意味します。