Как масштабировать функции Azure?

документация по масштабированию для Функций Azure немного освещает детали того, как Функции Azure решают когда добавлять больше экземпляров приложения.

Скажем, например, у меня есть функция, которая запускается веб-перехватчиком Github. 10 000 человек одновременно используют репозиторий Github (без конфликтов слияния;)), а Github вызывает мою функцию 10 000 раз за очень короткий период времени.

Что я могу ожидать? Конкретно,

  1. Будут ли функции Azure ограничивать вызовы веб-перехватчиков? т.е. будут ли функции Azure отклонять определенные вызовы функций, если мое приложение-функция находится под высокой нагрузкой?
  2. Служит ли функциям Azure каким-либо образом очереди запросов? Если да, то где / как?
  3. Сколько экземпляров моего приложения-функции будут созданы Функциями Azure в этом сценарии? По одному на каждый запрос (т. Е. 10 000), и каждый будет выполняться параллельно?
  4. Если бы моя функция приложения была уменьшена до нуля экземпляров, потому что на нее не было нагрузки, мог ли я ожидать увидеть некоторое «время разогрева» перед выполнением первой функции? Примерно как долго?

azure webhooks azure-functions
person Adrian Hofman    schedule 18.05.2016    source источник

Ответы (2)


arrow_upward
24
arrow_downward

  1. Функции Azure не отклоняют вызов веб-перехватчика, но в случае внезапной чрезмерной нагрузки некоторые запросы могут истекать по таймауту. Для веб-API рекомендуется включить повторную попытку на клиенте.
  2. Они не стоят в очереди ни на какое постоянное место. Они (детали реализации) управляются IIS.
  3. (Детали реализации) Количество экземпляров не является жесткой задачей. У нас есть определенные, неопубликованные средства защиты, но мы рассчитаны на довольно большие масштабы. Ваши запросы будут обрабатываться несколькими экземплярами.
  4. да. Прямо сейчас это довольно много (секунд), но мы будем работать над его улучшением. Для чувствительных к производительности ситуаций рекомендуется использовать канарейку или таймер, чтобы он не спал.

Я из команды Azure Functions. То, что я пометил как детали реализации, не является обещанием и, вероятно, также изменится по мере развития нашего сервиса; просто попытка прозрачности.

person Chris Anderson-MSFT    schedule 18.05.2016
comment
Не могли бы вы подробнее рассказать о триггере по таймеру? Могу ли я иметь еще одну функцию срабатывания таймера в приложении-функции и зависеть от нее, чтобы функции, запускаемые по HTTP, оставались «теплыми»? - person Shrulik; 24.04.2017
comment
Если у вас есть другая функция, такая как триггер таймера, в том же приложении-функции, она будет поддерживать теплый экземпляр для другого выполнения, сегодня, да. - person Chris Anderson-MSFT; 25.04.2017
comment
Спасибо. Сегодняшний день немного тревожит, но я ценю честность. - person Shrulik; 25.04.2017
comment
Это было сделано намеренно. Мы не обещаем, что не изменим поведение в будущем, но у нас нет текущих планов по его изменению и нет давления (например, нехватка возможностей), чтобы это изменить. Мы бы изменили его, если бы хотели увеличить использование наших ресурсов, но не раньше, чем сделаем холодный запуск не проблемой для людей. - person Chris Anderson-MSFT; 26.04.2017
comment
После некоторых экспериментов я думаю, что это неверно или больше не верно для предварительно скомпилированных функций azure. Я добавил функцию таймера, которая запускается каждую минуту, и легко подтвердить, что она действительно работает, поскольку все, что она делает, это записывает трассировку, и все же после примерно 10 минут бездействия я плачу за разогрев около 5-10 секунд. - person Shrulik; 30.04.2017
comment
Так быть не должно. Я бы создал новый вопрос с примерным периодом времени, и вы можете дать нам идентификатор вызова + регион, и мы сможем исследовать спящую активность. - person Chris Anderson-MSFT; 01.05.2017
comment
@ ChrisAnderson-MSFT: Могу ли я использовать Функции Azure для чтения всех больших двоичных объектов из заданного (активного) контейнера (например, содержащего журналы веб-приложений Azure) и отправки в другое место? Поскольку большой двоичный объект может быть добавлен несколько раз, данные, передаваемые в функцию через триггеры большого двоичного объекта, фактически перекрываются. Теоретически я могу вести учет количества прочитанных байтов для каждого большого двоичного объекта в отдельном месте (например, в хранилище таблиц), но тогда синхронизация является большой проблемой, поскольку разные триггеры одного и того же большого двоичного объекта будут обрабатываться разными функциями. - person David Ha; 10.07.2017

arrow_upward
6
arrow_downward

  1. протестировал сегодня. прошло больше секунды :(
ACTUAL PERFORMANCE
--------------
ClientConnected:  13:58:41.589

ClientBeginRequest:   13:58:41.592

GotRequestHeaders:    13:58:41.592

ClientDoneRequest:    13:58:41.592

Determine Gateway:    0ms

DNS Lookup:       65ms

TCP/IP Connect:   40ms

HTTPS Handshake:  114ms

ServerConnected:  13:58:41.703

FiddlerBeginRequest:  13:58:41.816

ServerGotRequest: 13:58:41.817

ServerBeginResponse:  14:00:36.790

GotResponseHeaders:   14:00:36.790

ServerDoneResponse:   14:00:36.790

ClientBeginResponse:  14:00:36.790

ClientDoneResponse:   14:00:36.790


Overall Elapsed:  **0:01:55.198**
person NoWhereToBeSeen    schedule 18.12.2016