Поставщик хранилища Azure для Durable Functions

При использовании Durable Functions поставщик Azure Storage используется по умолчанию для управления состоянием и оркестрацией. Поставщик Azure Storage оптимизирует производительность и масштабируемость приложений, сохраняя состояния экземпляра и очереди в учетной записи Azure Storage.

С поставщиком Azure Storage:

• Очереди Azure управляют выполнением всех функций.
• Azure Таблицы хранят оркестрацию, состояние сущности и историю.
• Azure объекты BLOB и аренда объектов BLOB распределяют экземпляры оркестрации и сущности между несколькими экземплярами приложений (также известными как рабочие процессы или виртуальные машины).

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

Представление хранилища

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

При создании концентратора задач поставщик Azure Storage настраивает эти компоненты в учетной записи хранения:

• таблицы Azure:
  • Две таблицы хранят ваши истории и состояния экземпляров.
  • Если включить управляющий разделами таблиц, дополнительная таблица хранит сведения о разделах.
• Очереди Azure:
  • Очередь Azure, в которой хранятся сообщения о действиях.
  • Одна или несколько очередей Azure, в которые хранятся сообщения экземпляров.
    • Каждая очередь управления представляет раздел, к которой назначено подмножество всех сообщений экземпляра на основе хэша идентификатора экземпляра.
• Azure BLOB-объекты:
  • Дополнительные контейнеры для аренды BLOB-объектов и/или больших сообщений.

Например, если вы назовете ваш центр задач xyz и установите PartitionCount = 4, вы увидите следующие очереди и таблицы:

Давайте рассмотрим каждый компонент и поймем, какую роль она играет.

• Таблица истории(xyzHistory)
• Таблица экземпляров(xyzInstances)
• Таблица секций
• Очередь рабочих элементов(xyz-workitems)
• Управление очередями(xyz-control-00, , xyz-control-01xyz-control-02, xyz-control-03)
• Blobs и аренда Blobs(xyz-largemessages, xyz-applease, xyz-leases)

Историческая таблица

Таблица History — это таблица Azure Storage, содержащая исторические события для всех экземпляров оркестрации данных в Task Hub, включая выходные данные из функций активности и суборчестратора, а также данные из внешних событий. Имя таблицы соответствует формату <TaskHubName>History. По мере запуска экземпляров в эту таблицу добавляются новые строки. В этой таблице:

• Ключ разбиения является производным от идентификатора экземпляра оркестрации. По умолчанию идентификаторы экземпляров являются случайными, обеспечивая оптимальное распределение внутренних секций в Azure Storage.
• Ключ строки — это порядковый номер, который упорядочивает исторические события.

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

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

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

Таблица экземпляров

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

• Ключ раздела — это идентификатор экземпляра оркестрации или ключ сущности.
• Ключ строки является пустой строкой. Каждый экземпляр оркестрации или сущности обычно имеет одну строку.

Таблица экземпляров удовлетворяет запросам экземпляров из кода и запросам состояния через HTTP API. Он в конечном итоге остается согласованным с содержимым таблицы History. Это разделение проблем следует шаблону сегрегации ответственности команд и запросов (CQRS), которая эффективно обрабатывает операции запроса экземпляра.

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

Таблица разделов

Таблица Partitions хранит состояние раздела для приложения Durable Functions и помогает распределять разделы между рабочими приложения. Каждый раздел имеет одну строку.

Queues

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

• Очередь рабочих элементов
• Очередь элементов управления

Очередь рабочих элементов

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

Управление очередями

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

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

• Сообщения управления Orchestrator
• Сообщения функции активности ответа
• Сообщения таймера

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

Фоновый поток постоянно опрашивает сообщения очереди управления. Настройте следующие параметры очереди в host.json:

• controlQueueBatchSize: Контролируйте размер пакета при каждом опросе очереди, по умолчанию это значение — 32 (максимальное значение, поддерживаемое очередями Azure).
• controlQueueBufferThreshold: управляет максимальным количеством предварительно извлечённых сообщений управляющей очереди, которые буферизуются в памяти. Значение по умолчанию зависит от таких факторов, как тип плана размещения.

Дополнительные сведения об этих параметрах см. в документации по схемеhost.json.

Опрос очередей

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

Можно настроить максимальную задержку опроса с помощью maxQueuePollingInterval свойства в host.json файле.

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

Задержки начала оркестрации

Инстанции оркестрации запускаются, когда система помещает ExecutionStarted сообщение в одну из очередей управления концентратора задач. При определенных условиях могут возникать задержки в несколько секунд между планированием выполнения оркестрации и её фактическим запуском. В течение этого интервала экземпляр оркестрации остается в Pending состоянии. Существуют две потенциальные причины этой задержки.

• Невыполненные очереди элементов управления:

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

  • События запуска оркестрации
  • Завершение действий
  • Устойчивые таймеры
  • Завершение
  • Внешние события

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

• Снижение задержек опроса:

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

  • У вас есть только один экземпляр приложения
  • Экземпляр приложения, запускающий оркестрацию, также является тем же экземпляром, который опрашивает очередь управления целевым контролем.

  Уменьшите задержки отклика опроса, обновив параметры host.json.

Блобсы

В большинстве случаев Durable Functions не использует Azure Storage Blobs для сохранения данных. Однако очереди и таблицы имеют ограничения размера, которые могут помешать Durable Functions сохранить все необходимые данные в строке хранилища или в сообщении очереди.

Например, если данные, которые нужно сохранить в очереди, имеют объём более 45 КБ при сериализации, Durable Functions сжимает их и сохраняет в блобе. При сохранении данных в хранилище Blob, Durable Functions сохраняет ссылку на этот Blob в строке таблицы или сообщении очереди. Когда Durable Functions необходимо получить данные, он автоматически извлекает их из объекта BLOB. Найдите эти объекты BLOB, хранящиеся в BLOB-контейнере <taskhub>-largemessages.

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

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

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

Хранение полезных данных на локальных дисках не рекомендуется, так как состояние на диске не гарантируется. Функции могут выполняться на разных виртуальных машинах в течение всего времени существования.

Настройка поставщика хранилища Azure

Поставщик хранилища Azure является поставщиком хранилища по умолчанию и не требует явной настройки, ссылок на пакеты NuGet или ссылок на пакеты расширений. Полный набор параметров конфигурации Durable Functions host.json можно найти по пути extensions/durableTask/storageProvider.

Connections

Свойство connectionName в host.json является ссылкой на конфигурацию среды, которая указывает, как приложение должно подключаться к Azure Storage. В данном свойстве может быть указано:

• Имя общего префикса для нескольких параметров приложения, объединяющее их в подключение на основе идентификатора. Управляемые идентификаторы используют аутентификацию Microsoft Entra для обеспечения наиболее безопасного подключения к учетной записи хранения.
• Имя параметра приложения, содержащего строку подключения. Чтобы получить строку подключения, выполните действия, описанные в разделе Управление ключами доступа к учетной записи хранения.

Если настроенное значение одновременно точно соответствует одному параметру и является префиксом для других параметров, то используется точное совпадение. Если значение не указано в host.json, значение по умолчанию равно AzureWebJobsStorage.

Подключения на основе идентификации

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

Чтобы использовать идентификационное соединение для Durable Functions, настройте следующие параметры приложения:

Для настройки подключения можно задать дополнительные свойства. См. раздел Общие свойства подключений на основе удостоверений.

При размещении в службе Azure Functions, подключения, основанные на идентификации, используют управляемую идентификацию. По умолчанию используется назначаемое системой удостоверение, однако вы можете указать назначаемое пользователем удостоверение с помощью свойств credential и clientID. Обратите внимание, что настройка назначаемого пользователем удостоверения с идентификатором ресурса не поддерживается. При выполнении в других контекстах, например при локальной разработке, вместо этого используется удостоверение разработчика, хотя это можно настроить. См. Локальная разработка с удостоверяющими подключениями.

Разрешение на предоставление удостоверению

Любая используемая идентификация должна иметь разрешения на выполнение запланированных действий. Для большинства служб Azure это означает, что необходимо назначить роль в Azure RBAC, используя встроенные или настраиваемые роли, которые предоставляют эти разрешения.

Вам потребуется создать назначение ролей, которое предоставляет доступ к хранилищу Azure во время выполнения. Ролей управления, таких как Владелец, недостаточно. При использовании расширения Durable Functions в обычной работе рекомендуется использовать следующие встроенные роли:

• Сотрудник по работе с BLOB-данными хранилища
• Конструктор данных очереди хранилища
• Сотрудник по работе с данными в таблицах хранилища

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

Выбор учетной записи хранения

Durable Functions создает очереди, таблицы и блобы, которые он использует в настроенной учетной записи Azure Storage. Вы можете указать, какую учетную запись использовать в файле host.json.

• Параметр durableTask/storageProvider/connectionStringName (Durable Functions 2.x)
• Параметр durableTask/azureStorageConnectionStringName (в Durable Functions 1.x)

{
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "connectionStringName": "MyStorageAccountAppSetting"
      }
    }
  }
}

{
  "extensions": {
    "durableTask": {
      "azureStorageConnectionStringName": "MyStorageAccountAppSetting"
    }
  }
}

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

• Для рабочих нагрузок с учетом производительности настройте учетную запись хранения, отличной от учетной записи по умолчанию (AzureWebJobsStorage). Так как Durable Functions активно использует Azure Storage, использование выделенной учетной записи хранилища изолирует использование хранилища Durable Functions от его внутреннего использования хостом Azure Functions.
• При использовании поставщика Azure Storage необходимо использовать стандартные учетные записи общего назначения Azure Storage. Все остальные типы учетных записей хранения в настоящее время не поддерживаются.
• Рекомендуется использовать устаревшие учетные записи хранения общего назначения версии 1 для Durable Functions. Более новые учетные записи хранения версии 2 могут быть дороже для рабочих нагрузок Durable Functions. Узнайте больше о типах учетных записей Azure Storage.

Масштабирование оркестратора

Хотя вы можете масштабировать функции активности в неограниченном количестве, добавляя виртуальные машины с эластичным масштабированием, отдельные экземпляры оркестратора и сущности ограничены размещением в одном разделе. Максимальное количество разделов ограничивается настройкой partitionCount в вашем host.json.

Вы определяете количество очередей элементов управления в host.json файле. В следующем примере фрагмент кода host.json задает свойство durableTask/storageProvider/partitionCount (durableTask/partitionCount в Durable Functions 1.x) значением 3. У вас столько очередей управления, сколько у вас разделов.

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

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

Вы можете настроить концентратор задач в диапазоне от 1 до 16 секций. Если значение не указано, число секций по умолчанию — четыре.

В сценариях с низким трафиком ваше приложение масштабируется, чтобы немногие обработчики управляли вашими партициями. Например, на следующей схеме можно увидеть, что оркестраторы 1–6 распределяются по секциям. Аналогичным образом, разделы, такие как процессы, распределяются по нагрузке между исполнителями. Балансировка нагрузки секций между рабочими ролей независимо от количества оркестраторов.

Если вы используете тарифные планы Azure Functions "Consumption" или "Эластичный премиум," или настроили автомасштабирование, основанное на нагрузке, то с увеличением трафика выделяется больше рабочих, а разделы в конечном итоге равномерно распределяют нагрузку между всеми рабочими. Если вы продолжаете масштабировать, в конечном итоге один рабочий управляет каждым разделом.

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

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

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

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

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

На следующей схеме показано, как узел Azure Functions взаимодействует с сущностями хранилища в масштабируемой среде.

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

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

Экземпляры оркестрации и сущности распределяются по всем экземплярам контрольной очереди. Распределение происходит путем хэширования идентификатора экземпляра оркестрации или имени сущности и пары ключей. Так как идентификаторы экземпляров оркестрации являются случайными идентификаторами GUID по умолчанию, экземпляры равномерно распределяются по всем очередям элементов управления.

Расширенные сеансы

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

Вы можете включить расширенные сеансы, задав параметр durableTask/extendedSessionsEnabled равным true в файле host.json. Вы можете использовать настройку durableTask/extendedSessionIdleTimeoutInSeconds для контроля того, как долго неактивный сеанс остается в памяти.

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

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

Помните о двух потенциальных недостатках этого параметра:

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

Например, если вы установите durableTask/extendedSessionIdleTimeoutInSeconds на 30 секунд, эпизод оркестратора или функции сущности, исполняющийся менее чем за 1 секунду, всё равно будет занимать память в течение 30 секунд. Он также засчитывается против указанной ранее квоты durableTask/maxConcurrentOrchestratorFunctions, что может предотвратить запуск других функций оркестратора или сущности.

Расширенные сеансы влияют на функции оркестратора и сущности по-разному. Рассмотрим, как они работают с функциями оркестратора.

Повторение функции оркестратора

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

Чаще всего можно наблюдать улучшение производительности расширенных сеансов, когда:

• У вас есть ограниченное количество экземпляров оркестрации, работающих одновременно.
• Ваши оркестрации содержат большое количество последовательных действий (например, сотни вызовов функций активности), которые выполняются быстро.
• Ваши оркестрации распределяют и объединяют множество действий, которые завершаются примерно одновременно.
• Функции оркестратора должны обрабатывать большие сообщения или выполнять обработку данных с интенсивным использованием процессора.

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

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

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

Экземпляр относится к одному экземпляру функции оркестратора, работающей на одной небольшой виртуальной машине (A1) в Azure App Service. Во всех случаях эти числа предполагают, что вы включили расширенные сеансы. Фактические результаты могут отличаться в зависимости от ЦП или ввода-вывода, выполняемого кодом функции.

Если вы не видите ожидаемых значений пропускной способности, а использование ЦП и памяти отображается работоспособным, проверьте, не связана ли это с работоспособностью учетной записи хранения. Расширение Durable Functions может вызвать значительную нагрузку на учетную запись Azure Storage, и достаточно высокая нагрузка может привести к ограничению скорости работы учетной записи хранения.

План потребления Flex

План потребления Flex — это план размещения Azure Functions, который предоставляет множество преимуществ плана потребления, в том числе:

• Бессерверная модель выставления счетов
• Частная сеть
• Выбор размера памяти экземпляра
• Полная поддержка проверки подлинности управляемого удостоверения

При размещении Durable Functions в плане Flex Consumption рекомендуется следовать этим рекомендациям.

• Установите количество всегда готовых экземпляров для группы durable на 1. Этот параметр гарантирует, что у вас всегда есть один экземпляр, готовый к обработке Durable Functions связанных запросов, что снижает холодный запуск приложения.
• Уменьшите интервал опроса очереди до 10 секунд или меньше. Так как этот тип плана более чувствителен к задержкам опроса очереди, снижение интервала опроса помогает повысить частоту таких операций, что обеспечивает более быстрое выполнение запросов. Однако более частые операции опроса приводят к более высоким затратам на учетную запись Azure Storage.

Обработка с высокой пропускной способностью

Архитектура серверной части Azure Storage накладывает определенные ограничения на максимальную теоретические производительность и масштабируемость Durable Functions. Если ваше тестирование показывает, что Durable Functions в Azure Storage не соответствуют требованиям к пропускной способности, вместо этого следует использовать поставщика хранилища Netherite для Durable Functions.

Сравните достижимую пропускную способность для различных базовых сценариев.

Серверная часть хранилища Netherite спроектирована и разработана в Microsoft Research. В нем используются Azure Event Hubs и технология базы данных FASTER поверх Azure Page Blobs. Дизайн Netherite позволяет обработку оркестраций и сущностей с более высокой пропускной способностью в сравнении с другими поставщиками. В некоторых сценариях теста пропускная способность увеличивается на более чем порядок величины по сравнению с поставщиком Azure Storage по умолчанию.

Дополнительные сведения о поддерживаемых поставщиках хранилища для Durable Functions и их сравнении см. в документации о поставщиках хранилища для Durable Functions.

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