Ограничения в устойчивых функциях Azure. Макс. действия и оркестраторыPython

Программы на Python
Ответить Пред. темаСлед. тема
Anonymous
 Ограничения в устойчивых функциях Azure. Макс. действия и оркестраторы

Сообщение Anonymous »


Пожалуйста, поддержите меня в этом вопросе; вопросы обобщены внизу сообщения.

Я несколько раз читал информацию о масштабируемости Azure на этой странице, но все еще не уверен в своем подходе к этой проблеме.

Вот сценарий: у нас есть множество алгоритмов, которые необходимо запускать параллельно на нескольких системах. Например, один из этих алгоритмов рассчитывает отклонения температуры в различных помещениях здания. Чтобы реализовать это, я использую Durable Functions. Первоначально оркестратор идентифицирует все комнаты, а затем инициирует действие для каждой комнаты. Эти действия собирают необходимые данные, вычисляют отклонение, публикуют результаты и возвращают отклонение Оркестратору. Этот алгоритм может потребоваться запустить в 100 зданиях, каждое из которых содержит 100 комнат (систем), всего для запуска 10 000 функций активности. Я бы хотел, чтобы Оркестратор запускался по таймеру каждые 5 минут.

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

Предполагая, что вызовы API асинхронны, а вычисления упрощены, кажется ли этот подход хорошим?

Экспериментатор:

Чтобы получить больше опыта, я провел эксперимент. В этом эксперименте я создал пять алгоритмов, каждый из которых обозначен разным цветом. На оси Y отображается идентификатор каждого действия или оркестратора, а на оси X представлена ​​продолжительность каждого действия или оркестратора с момента срабатывания, которое, например, составляет 13:05:00, поскольку оно происходит каждые пять минут.

Большие горизонтальные полосы обозначают оркестраторов, которые начинают работу примерно в одно и то же время, с нулевой секунды. Затем оркестратор проходит этап инициализации, на котором он получает настройки, системы и другие необходимые данные. Важно отметить, что код оркестратора, как упоминалось здесь, является детерминированным. После этой фазы инициализации он начинает инициировать функции активности для каждой системы. Однако, поскольку для maxConcurrentActivityFunctions установлено значение 50, мы можем наблюдать, что он запускает 50 действий почти параллельно. После этих первоначальных 50 действий наступает пауза продолжительностью почти 7 секунд, о чем свидетельствуют оранжевые действия между отметками 12 и 19 секунд. Вопрос: почему происходит эта задержка?

Этот эксперимент выполняется локально, код написан на Python, а хост-файл выглядит следующим образом:

{ "версия": "2.0", "Ведение журнала": { "logLevel": { «Функция»: «Информация», «Работник»: «Ошибка», «Хост.Агрегатор»: «Информация», «Майкрософт»: «Ошибка», "Host.Results": "Ошибка" }, "applicationInsights": { "Настройки выборки": { «isEnabled»: правда, "excludedTypes": "Запрос" } } }, "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "версия": "[3.3.0, 4.0.0)" }, "параллелизм": { «dynamicConcurrencyEnabled»: правда, «snapshotPersistenceEnabled»: правда }, "расширения": { "durableTask": { "storageProvider": { "type": "AzureStorage" }, «maxConcurrentActivityFunctions»: 50, «maxConcurrentOrchestratorFunctions»: 50 } } }
Изображение


Мой желаемый результат — чтобы все действия выполнялись параллельно и одновременно. Чтобы проверить это, я поэкспериментировал с увеличением значений maxConcurrentActivityFunctions и maxConcurrentOrchestratorFunctions. На этом изображении я установил оба значения равными 1000, просто ради эксперимента. Однако мы все же можем наблюдать некоторые заметные разрывы или задержки между выполнением функций деятельности. Например, существует разрыв в зеленых действиях между отметками 23 и 26 секунд. Важно отметить, что этот эксперимент проводится локально, поэтому могут иметь место и другие ограничения или факторы, о которых я не до конца осведомлен.


Изображение


Вопросы:
[*]Подходит ли решение, упомянутое для описанного сценария? [*]Какие конкретные ограничения мне следует учитывать в этом контексте? [*]Почему не все функции активности запускаются одновременно? [*]Чем объясняется разрыв в несколько секунд между определенными действиями? [*]Существуют ли какие-либо ограничения на значения maxConcurrentActivityFunctions и maxConcurrentOrchestratorFunctions? Каково максимально допустимое значение этих параметров? [*]Я нашел информацию о суборкестраторах. Было бы полезно включить их в этот подход?
Я очень ценю любые отзывы, особенно касающиеся подхода и идеи. В настоящее время у меня нет лучшего решения.

Спасибо!
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение
  • Ограничения в устойчивых функциях Azure. Макс. действия и оркестраторы
    Anonymous » » в форуме Python
    0 Ответы
    38 Просмотры
    Последнее сообщение Anonymous
  • Как использовать триггеры очереди в устойчивых функциях Python Azure с управляемым удостоверением
    Anonymous » » в форуме Python
    0 Ответы
    25 Просмотры
    Последнее сообщение Anonymous
  • Проблема с производительностью устойчивых функций Python Azure
    Anonymous » » в форуме Python
    0 Ответы
    23 Просмотры
    Последнее сообщение Anonymous
  • Использование HttpClient с DelegatingHandler в устойчивых оркестрациях Azure
    Anonymous » » в форуме C#
    0 Ответы
    12 Просмотры
    Последнее сообщение Anonymous
  • Использование HttpClient с DelegatingHandler в устойчивых оркестрациях Azure
    Anonymous » » в форуме C#
    0 Ответы
    23 Просмотры
    Последнее сообщение Anonymous

Вернуться в «Python»