Несколько экземпляров непрерывного веб-задания на одной виртуальной машине в Azure

На моем веб-сайте Azure постоянно выполняется веб-задание. Он отвечает за выполнение некоторой работы после получения элементов из QueueTrigger. Я пытаюсь увеличить скорость обработки элементов вне очереди. По мере того, как я масштабирую свой план службы приложений, скорость обработки увеличивается, как и ожидалось.

Меня беспокоит то, что оплачивать дополнительные виртуальные машины просто для запуска дополнительных экземпляров моего Webjob кажется бесполезным. Я ищу варианты / рекомендации для запуска нескольких экземпляров одного и того же Webjob на одном сервере.

Я пробовал запускать несколько JobHosts в отдельных потоках внутри Main (), но либо это не сработало, либо я делал что-то не так ... Webjob не запускался из-за того, что похоже, что каждый поток пытается получить доступ к WebJobSdk. маркер '. Мое текущее решение состоит в том, чтобы публиковать мое веб-задание несколько раз, каждый раз слегка изменяя «webJobName» в «webjob-publish-settings.json», чтобы один и тот же проект считался другим веб-заданием во время публикации. Пока что это отлично работает, ожидайте, что это создает много дополнительной работы каждый раз, когда мне нужно сделать какое-либо обновление.

В конце концов, я ищу несколько советов о том, какой рекомендуемый способ сделать это. В идеале я хотел бы, чтобы несколько экземпляров выполнялись через код, и мне нужно было публиковать только один раз, когда мне нужно обновить код.

Есть какие-нибудь мысли?


person Gadget27    schedule 22.09.2015    source источник


Ответы (1)


Вы можете использовать настройки JobHostConfiguration.QueuesConfiguration. BatchSize и NewBatchThreshold для управления уровнем параллелизма обработки вашей очереди. Последний параметр NewBatchThreshold является новым в текущей версии beta1. Однако, включив «предварительные» пакеты в диспетчере пакетов Nuget, вы увидите новый выпуск, если хотите его попробовать. Повышение параметра NewBatchThreshold увеличивает уровень параллелизма - например, установка значения 100 означает, что как только количество выполняемых в данный момент функций очереди упадет ниже 100, будет получен новый пакет сообщений для одновременной обработки.

Ошибка файла маркера была исправлена ​​в этом коммите некоторое время назад и снова. является частью текущего выпуска v1.1.0.

person mathewc    schedule 22.09.2015
comment
Спасибо, что предупредили меня об этой новой функции в следующей версии. Я уже экспериментировал с BatchSize, а теперь и с NewBatchThreshold. Похоже, я добиваюсь небольшого успеха, увеличивая порог, и я вижу улучшения в всплесках, но устойчивые в течение длительного времени, наличие нескольких экземпляров веб-задания работает лучше всего для меня, поэтому я все еще ищу лучший подход для этого. - person Gadget27; 22.09.2015
comment
@ Gadget27 Я в той же ситуации, что и ты. Я увеличил размер BatchSize до 32, а также несколько раз дублировал WebJob в одном экземпляре сервера. В основном репликация кодов из MyWebJob в MyWebJob2, MyWebJob3 и MyWebJob4 с последующим развертыванием всех четырех веб-заданий на одном экземпляре сервера. Таким образом, увеличив BatchSize до 4x32. - person Minh Nguyen; 21.10.2015
comment
@staticmain Я делаю нечто подобное, но я не копирую код в несколько отдельных проектов веб-заданий. Вместо этого у меня есть одно веб-задание, и я развертываю его x количество раз, каждый раз изменяя параметры webJobName в webjob-publish-settings.json, чтобы каждое событие публикации использовало уникальное имя. (JobInstanceA, JobInstanceB, JobInstanceC и т. Д.). Конечные результаты должны быть одинаковыми, но я подозреваю, что использование одного проекта значительно упростит управление кодом. - person Gadget27; 21.10.2015