У меня есть веб-задание, которое запускается, когда пользователь загружает файл в хранилище BLOB-объектов - он запускается сообщением хранилища очереди, которое создается после завершения загрузки.
В зависимости от назначения файла он будет отправлять сообщения в другие очереди для запуска заданий обработки.
Некоторые из этих заданий критичны по времени и выполняются относительно быстро. В одном случае обработка занимает около трех секунд, и пользователь ждет результата.
Однако, поскольку минимальный интервал опроса очереди составляет 2 секунды, время, в течение которого пользователь должен ждать вызова двух веб-заданий, обычно удваивает их время ожидания.
Я попытался объединить два веб-задания в одно, надеясь, что, когда первый обработчик отправит сообщение в очередь, соответствующий обработчик обработки будет немедленно запущен, но на самом деле он постоянно ждет две секунды, прежде чем забрать сообщение.
Мой вопрос: могу ли я сказать своему веб-заданию, чтобы я немедленно проверял триггеры очереди из того же веб-задания, если я знаю, что есть ожидающее сообщение? Или еще лучше настроить его для немедленной проверки триггеров очереди, если я отправляю в очередь изнутри WebJob?
Или переключение на очередь служебной шины улучшило бы реакцию на новые сообщения?
Обновить
В документации об использовании триггеров больших двоичных объектов говорится:
Есть исключение для больших двоичных объектов, которые вы создаете с помощью атрибута Blob. Когда пакет SDK WebJobs создает новый большой двоичный объект, он немедленно передает новый большой двоичный объект всем подходящим функциям BlobTrigger. Поэтому, если у вас есть цепочка входов и выходов больших двоичных объектов, SDK может эффективно их обрабатывать. Но если вам нужна низкая задержка при выполнении функций обработки больших двоичных объектов для больших двоичных объектов, которые создаются или обновляются другими способами, мы рекомендуем использовать QueueTrigger, а не BlobTrigger.
Однако для очередей ничего подобного не упоминается. Это означает, что если в этом сценарии вам нужна действительно низкая задержка, то капли лучше, чем очереди, что кажется неправильным.
Обновление 2
В конце концов, я решил обойти это, вытащив код оркестровки из первого WebJob на сервисный уровень приложения и удалив WebJob. В любом случае он работал быстро, поэтому, возможно, разделение его на собственное WebJob было излишним. Это означает, что после загрузки файла должна запускаться только обработка веб-задания.
