Производительность и масштабирование в устойчивых функциях

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

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

Масштабирование рабочих ролей

Ключевым преимуществом концепции концентратора задач является то, что число рабочих, обрабатывающих рабочие элементы концентратора задач, масштабируется вверх и вниз. Приложения добавляют рабочих (горизонтальное масштабирование) для ускорения обработки и удаляют рабочих (горизонтальное масштабирование), когда недостаточно работы, чтобы их занять. Вы даже можете масштабировать до нуля , если концентратор задач неактивен. При масштабировании системы до нуля не выполняются рабочие процессы. Только контроллер масштабирования и хранилище остаются активными.

Эта концепция представлена на схеме ниже:

Автоматическое масштабирование

В планах Consumption и Elastic Premium, Устойчивые функции поддерживает автомасштабирование с помощью контроллера масштабирования Функции Azure. Контроллер масштабирования отслеживает время ожидания сообщений и задач перед обработкой. На основе этих задержек он добавляет или удаляет работников.

В плане "Премиум" автоматическое масштабирование сохраняет количество рабочих (и операционных затрат) примерно пропорционально нагрузке приложения.

Ограничители параллелизма

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

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

Настройка ограничения параллелизма

Настройте ограничения параллелизма действий, оркестратора и сущностей в файле host.json . Используйте durableTask/maxConcurrentActivityFunctions для функций активности и durableTask/maxConcurrentOrchestratorFunctions для функций оркестратора и сущностей. Эти параметры ограничивают количество функций оркестратора, сущностей и активности, которые рабочий загружает в память.

{
  "extensions": {
    "durableTask": {
      "maxConcurrentActivityFunctions": 10,
      "maxConcurrentOrchestratorFunctions": 10
    }
  }
}

Соображения по языковой среде выполнения

Выбранная среда выполнения языка может накладывать строгие ограничения параллелизма для функций. Например, Устойчивые функции приложения, написанные в Python или PowerShell, могут выполнять только одну функцию одновременно на одной виртуальной машине. Это может привести к проблемам с производительностью, если вы не учитываете его. Если оркестратор распределяет 10 активностей, но рантайм позволяет запускать только одну функцию, девять из 10 функций активностей остаются в ожидании возможности выполнения. Кроме того, эти действия ожидания нельзя распределить между другими работниками, так как среда выполнения Устойчивые функции уже загружает их в память. Это особенно проблематично, когда функции активности выполняются в течение длительного времени.

Если среда выполнения вашего языка ограничивает параллельное выполнение, обновите параметры параллельного выполнения в Устойчивые функции для соответствия. Это предотвращает выполнение средой выполнения Устойчивые функции большего количества функций одновременно, чем позволяет языковая среда, и позволяет распределять невыполненные действия по другим виртуальным машинам. Например, если приложение Python ограничивает параллелизм четырьмя функциями (например, 4 потока для одного рабочего процесса языка или 1 потока на 4 рабочих процессах языка), настройте как maxConcurrentOrchestratorFunctions, так и maxConcurrentActivityFunctions до 4.

Рекомендации по увеличению производительности Python см. в статье Улучшение пропускной способности приложений Python в Функции Azure. Эти методы могут значительно повысить производительность и масштабируемость Устойчивые функции.

Кэширование экземпляров

Чтобы обработать рабочий элемент оркестрации, работник выполняет две действия:

1. Получение истории оркестрации.
2. Воспроизведите код оркестратора с помощью истории.

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

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

Кэширование поставщиком хранилища

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

Расширенные сеансы (поставщик службы хранения Azure) удерживают оркестраторы в процессе выполнения в памяти, пока они не останутся неактивными заданное время. Включите и настройте это поведение с помощью extendedSessionsEnabled и extendedSessionIdleTimeoutInSeconds в файле host.json:

{
  "extensions": {
    "durableTask": {
      "extendedSessionsEnabled": true,
      "extendedSessionIdleTimeoutInSeconds": 30
    }
  }
}

Кэш экземпляров (поставщик хранилища Netherite) сохраняет состояние экземпляра и историю состояний в памяти работника и отслеживает общее использование памяти. Если кэш превышает InstanceCacheSizeMB ограничение, он вытесняет наименее недавно использованные данные экземпляра. Если вы установите CacheOrchestrationCursors на true, кэш также сохраняет оркестраторы в процессе выполнения.

Число разделов

Некоторые поставщики хранилища поддерживают секционирование и позволяют задавать.partitionCount

С разделением работники не конкурируют за отдельные задания. Секционирование групп рабочих элементов в partitionCount секции, а среда выполнения назначает секции рабочим группам. Такой подход сокращает общее количество доступа к хранилищу. Кроме того, он обеспечивает кэширование экземпляров и улучшает локальность путем создания сходства: один и тот же рабочий процесс обрабатывает все рабочие элементы для одного экземпляра.

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

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

Настройка счетчика секций

Укажите partitionCount в файле host.json . Следующий фрагмент кода host.json устанавливает durableTask/storageProvider/partitionCount на 3.

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "partitionCount": 3
      }
    }
  }
}

Поведение выполнения функции

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

Размещение работы по типу функции

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

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

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

Таймауты функций

Функции активности, оркестратора и сущностей подвержены тем же таймаутам функций, что и другие функции Azure. Устойчивые функции обрабатывает время ожидания функции как необработанное исключение в коде.

Например, когда время выполнения действия в Устойчивые функции истекает, система фиксирует выполнение как неудачное и уведомляет координатора. Оркестратор обрабатывает время ожидания подобно любому другому исключению: среда выполнения повторяет попытку, если в вызове указано повторение попыток, либо запускается обработчик исключений.

Пакетная обработка операций с сущностями

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

По умолчанию максимальный размер пакета составляет 50 в плане потребления и 5000 в других планах. Можно также настроить максимальный размер пакета в файлеhost.json . Если максимальный размер пакета равен 1, пакетная обработка фактически отключена.

Цели производительности

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

• Последовательное выполнение действия. В этом сценарии описывается функция оркестратора, которая выполняет ряд функций действий в последовательности. Он больше всего похож на пример цепочки функций .
• Параллельное выполнение активностей: В этом сценарии описывается функция оркестратора, которая выполняет множество функций активностей параллельно с использованием шаблона расхождения и схождения.
• Обработка параллельных ответов: это вторая половина шаблона разветвления и слияния. Он фокусируется на производительности вентилятора. В отличие от fan-out, fan-in выполняется в одном экземпляре функции оркестратора, поэтому она выполняется на одной виртуальной машине.
• Обработка внешних событий: этот сценарий представляет один экземпляр функции оркестратора, который ожидает внешних событий по одному за раз.
• Обработка операций сущностей. Этот сценарий проверяет, как быстро однасущность Счетчика может обрабатывать постоянный поток операций.

Номера пропускной способности для этих сценариев находятся в документации поставщика хранилища. В частности:

• Сведения о поставщике служба хранилища Azure см. в разделе Перформанс целевых объектов.
• Сведения о поставщике хранилища Netherite см. в основных сценариях.
• Сведения о поставщике хранилища MSSQL см. в разделе "Тесты пропускной способности оркестрации".

Дальнейшие действия