Поведение функции azure, вызванное масштабированием очереди, в AppServicePlan

Я разработал лазерную функцию, запускающуюся по очереди, на C #. Функция работает в плане AppService. Мы хотим реализовать собственное автоматическое масштабирование. Мы планируем увеличить количество экземпляров на 1, когда процент использования ЦП превышает 60%.

Мои вопросы:

  1. Это хорошая идея - увеличить количество экземпляров на 60%?
  2. Я провел исследование и обнаружил, что для функции Azure, запускаемой BLOB-объектами, существует механизм, который не позволит двум экземплярам выбрать одну и ту же запись в очереди. Это тот же механизм для функции Azure, запускаемой очередью C #?
  3. В моем коде функции я написал Thread.Sleep (3000), чтобы засыпать поток в некоторых условиях. Может ли это вызвать проблемы при масштабировании?
  4. Есть ли что-нибудь еще, что я должен учитывать при масштабировании в моем сценарии?

Заранее спасибо.


azure azure-functions azure-app-service-plans queuetrigger scaling
person Yash    schedule 24.06.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это хорошая идея - увеличить количество экземпляров на 60%?

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

  • Увеличьте количество экземпляров на 1 счет, если процент ЦП ›= 80
  • Уменьшите количество экземпляров на 1 счет, когда CPU% ‹= 60

Я провел исследование и обнаружил, что для функции Azure, запускаемой BLOB-объектами, существует механизм, который не позволит двум экземплярам выбрать одну и ту же запись в очереди. Это тот же механизм для функции Azure, запускаемой очередью C #?

Да не беспокойся об этом.

В моем коде функции я написал Thread.Sleep (3000), чтобы засыпать поток в некоторых условиях. Может ли это вызвать проблемы при масштабировании?

No.

Есть ли что-нибудь еще, что я должен учитывать при масштабировании в моем сценарии?

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

person Tony Ju    schedule 25.06.2020
comment
Спасибо за ответ. У меня есть один вопрос, связанный с вашим ответом в пункте 2. В настоящее время без горизонтального масштабирования я иногда получаю сообщение об ошибке «Поток был прерван» в функции Azure, запускаемой с помощью очереди. В этот момент запускается новый поток или функция, а старый прерывается. Но за долю секунды, прежде чем старый поток прервется, оба потока работают одновременно. И за это время они оба выбирают одну и ту же запись в очереди. Я знал это, регистрируя каждый шаг своей функции. Почему это происходит, если у лазурной функции триггера очереди есть механизм, позволяющий избежать этого? - person Yash; 25.06.2020