Экземпляры функции задания масштабирования триггера EventHub в функциях Azure

У меня есть функция Azure с триггером EventHub с планом потребления. В моем тесте я снимал 3000 событий в концентратор событий, используя несколько партий. Поскольку время для этих 3000 событий было почти в 10 раз больше, чем время для 300 событий, я подозревал, что эта функция Azure не масштабируется на несколько виртуальных машин / экземпляров.

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

Это происходит, даже если я укажу следующую конфигурацию в host.json: "eventHub": {"maxBatchSize": 1, "prefetchCount": 10}

Логика заключалась в том, что это ограничит параллельную обработку в пределах одного экземпляра, и из-за этого будет запущено несколько экземпляров, но опять же, в журнал регистрируется только 1 Guid.

Отметим, что это не единственная функция в службе приложений. Может быть, в этом проблема? Какое условие необходимо выполнить, чтобы функция запускалась на нескольких виртуальных машинах?

Изменить: у меня 32 раздела и 20 единиц пропускной способности. Первая проблема заключалась в том, что я использовал SendBatchAsync, который не разделяет события. Даже SendAsync не принес никакого масштаба, как будто он не разбивал. Поэтому я создал разделенных отправителей концентраторов событий и выполнил циклическое разделение при отправке событий в клиентском приложении.

Это увеличило количество событий, обрабатываемых AzureFunction, но по-прежнему не создавало более 1 виртуальной машины. Кроме того, количество событий, обрабатываемых в секунду, было намного больше в начале (~ 200 в каждый момент), а после 2000 событий или ближе к концу они упали до ~ 5. Это не имеет ничего общего с загрузкой системы, так как такое же поведение наблюдалось с 9000 событий, где замедление происходило после ~ 5k событий.

Эта функция Azure длится 50–250 мс, в зависимости от нагрузки. Он также отправляет событие в другую функцию Azure через триггер очереди хранилища Azure. Интересно то, что ни одна функция, которая запускается триггером очереди, не масштабируется до более чем 1 виртуальной машины, и в начале она имеет ~ 1k сообщений в очереди, до того, как функция azure запускает медленную работу концентратора событий. Параметры очереди в host.json: "queues": {"maxPollingInterval": 2000, "visibilityTimeout": "00:00:10", "batchSize": 32, "maxDequeueCount": 5, "newBatchThreshold": 1}

Спасибо.


person Vukasin    schedule 18.04.2017    source источник
comment
На сколько разделов были распределены эти события?   -  person Mikhail Shilkov    schedule 19.04.2017
comment
Концентратор событий имеет 32 раздела. Я начал использовать секционированный отправитель eventhub и получил немного лучшую производительность, но все равно использовалась только 1 виртуальная машина.   -  person Vukasin    schedule 19.04.2017


Ответы (1)


Это зависит от нескольких факторов:

  • количество разделов, имеющихся в вашем концентраторе событий, и то, распределяются ли записываемые вами события по вашим разделам. Функции Azure используют хост обработчика событий для обработки вашей рабочей нагрузки, и максимальный масштаб, который вы можете получить в этом режиме, составляет одну виртуальную машину на раздел.
  • рабочая нагрузка для каждого события, которую вы выполняете. Например, если ваша функция ничего не делает, кроме регистрации, эти 3000 событий могут быть обработаны менее чем за 5 секунд на одной виртуальной машине. Это не гарантирует масштабирования вашего приложения на несколько экземпляров.

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

person Paul Batum    schedule 19.04.2017
comment
У меня 32 раздела. Первая проблема заключалась в том, что я использовал SendBatchAsync, который не разделяет события. Даже SendAsync не принес никакого масштаба, как будто он не разбивал. Поэтому я создал разделенных отправителей концентратора событий и выполнил циклическое разделение при отправке событий в клиентском приложении. - person Vukasin; 19.04.2017
comment
Я отредактировал вопрос с дополнительной информацией. Спасибо за ответ. - person Vukasin; 19.04.2017
comment
Добавляя к комментарию Пола, каждый экземпляр функции поддерживается 1 EventProcessorHost (EPH). EventHub позволяет только 1 EPH удерживать в аренду раздел, но ›1 раздел может быть назначен EPH. В начале у вас есть 1 экземпляр функции = ›1 EPH (EPH0). EventHub обнаруживает, что EPH0 пытается подключиться к нему, и назначает ему все 32 раздела. Если EPH0 способен обрабатывать все события до того, как сработает логика масштабирования, тогда вам понадобится только 1 экземпляр функции. Для получения дополнительных сведений см. stackoverflow.com/questions/42901284/ - person Ling Toh; 20.04.2017
comment
Я вижу, он действительно способен обрабатывать все события в короткие сроки. Логика моего приложения такова, что каждая пара входных событий генерирует 1 событие, поэтому более поздняя функция замедляется - потому что в хабе событий нет событий. Однако странно, что они не производятся быстрее. Поскольку генерировать события является функция, запускаемая по очереди, я попытаюсь изучить, как увеличить масштаб для функции, запускаемой по очереди. У меня уже есть идеи из других вопросов. Спасибо! - person Vukasin; 20.04.2017