Бөлісу құралы:

Поставщик службы хранилища Azure (Функции Azure)

  • Мақала

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

Примечание.

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

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

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

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

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

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

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

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

Ниже будут подробно описаны эти компоненты и их роль.

Таблица журнала

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

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

Совет

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

Экземпляры таблицы

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

Эта таблица используется для удовлетворения запросов экземпляра от кода и API HTTP запросов состояния. В конечном итоге она поддерживается в соответствии с содержанием таблицы Журнала, упомянутой ранее. Использование отдельных таблиц хранилища Azure для эффективного удовлетворения операций запроса экземпляров, является путем, обусловленным шаблоном CQRS.

Совет

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

Таблица секций

Примечание.

Эта таблица отображается в концентраторе задач только в том случае, если Table Partition Manager он включен. Чтобы применить его, настройте useTablePartitionManagement параметр в host.json приложения.

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

Очереди

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

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

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

Очередь управления

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

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

Сообщения очереди управления постоянно опрашиваются с помощью фонового потока. Размер пакета каждого опроса очереди управляется параметром controlQueueBatchSize, содержащимся в файле в host.json, и имеет значение по умолчанию 32 (максимальное значение, поддерживаемое очередями Azure). Максимальное число предварительно доставленных сообщений очереди управления в буфере памяти управляется параметром controlQueueBufferThreshold из файла host.json. Значение по умолчанию controlQueueBufferThreshold зависит от множества факторов, включая тип плана размещения. Дополнительные сведения об этих параметрах см. в документации Схема host.jsв.

Совет

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

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

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

Максимальное время ожидания опроса настраивается при помощи свойства maxQueuePollingInterval в файле host.json. Установка для этого свойства более высокого значения может привести к увеличению задержек при обработке сообщения. Более высокие задержки могут ожидаться только после периодов бездействия. Установка для этого свойства более низкого значения может привести к увеличению затрат на хранение данных из-за повышенного числа транзакций хранилища.

Примечание.

При выполнении в планах потребления службы "Функции Azure" и "Премиум" контроллер масштабирования Функций Azure будет опрашивать каждый элемент управления и очередь рабочих элементов каждые 10 секунд. Этот дополнительный опрос необходим для определения времени активации экземпляров приложения-функции и принятия решений о масштабировании. На момент написания статьи этот интервал 10 секунд является постоянным и не может быть настроен.

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

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

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

  • Отсрочка задержек опроса. Еще одна распространенная причина задержки оркестрации — это ранее описанное поведение опроса для управляющих очередей. Однако эта задержка ожидается только в том случае, если приложение масштабируется до двух или более экземпляров. Если существует только один экземпляр приложения либо если экземпляр приложения, запускающий оркестрацию, является тем же экземпляром, который опрашивает целевую очередь управления, то задержки опроса очереди не будет. Можно сократить отсрочку задержек при опросе, обновив параметры в файле host.json, как описано выше.

BLOB-объекты

В большинстве случаев Устойчивые функции не используют большие двоичные объекты службы хранилища Azure для сохранения данных. Однако очереди и таблицы имеют ограничения по размеру, которые могут препятствовать сохранению Устойчивыми функциями всех необходимых данных в строке хранилища или в сообщении очереди. Например, если фрагмент данных, который необходимо сохранить в очереди, превышает 45 КБ при сериализации, Устойчивые функции будут сжимать данные и хранить их в большом двоичном объекте. При таком сохранении данных в хранилище больших двоичных объектов Устойчивая функция сохраняет ссылку на этот большой двоичный объект в строке таблицы или в сообщении очереди. Когда Устойчивым функциям необходимо получить данные, они будут автоматически извлекать их из большого двоичного объекта. Эти большие двоичные объекты хранятся в контейнере больших двоичных объектов <taskhub>-largemessages.

Замечания, связанные с быстродействием

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

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

Очереди, таблицы и BLOB-объекты, используемые устойчивыми функциями, создаются в настроенной учетной записи службы хранения Azure. Используемую учетную запись можно указать с помощью параметра durableTask/storageProvider/connectionStringName (или параметра durableTask/azureStorageConnectionStringName для устойчивых функций 1.x) в файле host.json.

Устойчивые функции 2.x

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

Устойчивые функции 1.x

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

Если значение не указано, учетная запись AzureWebJobsStorage используется по умолчанию. Однако, для рабочих нагрузок, требующих высокой производительности, рекомендуется настроить учетную запись хранения, кроме используемой по умолчанию. Устойчивые функции сильно полагаются на хранилище Azure и используют отдельную учетную запись хранения для изоляции использования хранилища устойчивых функций узлом функций Azure.

Примечание.

Учетные записи хранения Azure общего назначения (цен. категория "Стандартный") требуются при использовании поставщика хранилища Azure. Другие типы учетных записей хранения не поддерживаются. Для устойчивых функций настоятельно рекомендуется использовать устаревшие (версии 1) учетные записи хранения общего назначения. Более новые учетные записи хранения (версии 2) могут оказаться значительно дороже для рабочих нагрузок устойчивых функций. Дополнительные сведения о типах учетных записей хранения Azure см. в документации Общие сведения об учетных записях хранения Azure.

Развертывание оркестратора

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

Примечание.

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

Число очередей управления определено в файле host.json. В следующем примере фрагмента кода host.json свойство durableTask/storageProvider/partitionCount (или durableTask/partitionCount для устойчивых функции 1.x) устанавливается в значение 3. Обратите внимание, что существует столько же управляющих очередей, сколько есть секций.

Устойчивые функции 2.x

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

Устойчивые функции 1.x

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

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

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

Схема уменьшения масштаба оркестраций

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

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

Первая схема масштабируемой оркестрации

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

Примечание.

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

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

Вторая схема масштабируемой оркестрации

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

На схеме ниже показано взаимодействие узла Функций Azure с сущностями хранилища в развернутой среде.

Схема масштабирования

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

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

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

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

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

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

Функции 2.0

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

Функции 1.0

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

Существует два возможных недостатка этого параметра, которые следует учитывать.

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

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

Конкретные эффекты расширенных сеансов для функций оркестратора или сущности описаны в следующих разделах.

Примечание.

В настоящее время расширенные сеансы поддерживаются только на языках .NET, таких как C# и F#. Установка параметра extendedSessionsEnabled в true для других платформ может привести к проблемам во время выполнения, например к сбою выполнения действия или активированной триггером функции оркестрации без предоставления об этом информации.

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

Как было упомянуто ранее, функции оркестратора воспроизводятся с помощью содержимого таблицы Журнал. По умолчанию код функции оркестратора воспроизводится каждый раз, когда пакет сообщений удаляется из очереди управления. Даже при развертывании, свертывании и ожидании завершения всех задач (например, с помощью Task.WhenAll() в .NET, context.df.Task.all() в JavaScript или context.task_all() в Python) в процессе обработки пакетов с ответами задач будут существовать повторы. Когда расширенные сеансы включены, экземпляры функции оркестратора остаются в памяти дольше и новые сообщения могут обрабатываться без полного воспроизведения истории.

Повышение производительности для расширенных сеансов чаще всего наблюдается в следующих ситуациях.

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

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

Примечание.

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

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

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

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

Сценарий Максимальная пропускная способность
Выполнение последовательного действия 5 действий на экземпляр в секунду
Параллельное выполнение одного действия (при развертывании) 100 действий на экземпляр в секунду
Параллельная обработка ответа (при слиянии) 150 ответов на экземпляр в секунду
Обработка внешних событий 50 событий на экземпляр в секунду
Обработка операций сущности 64 операции в секунду

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

Совет

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

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

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

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

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

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

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

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

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

Серверная часть хранилища Netherite спроектирована и разработана в Microsoft Research. В Netherite используются концентраторы событий Azure и более быстрая технология базы данных поверх страничных BLOB-объектов Azure. Структура Netherite обеспечивает значительно более высокую пропускную способность обработки оркестраций и сущностей по сравнению с другими поставщиками. В некоторых сценариях тестирования зафиксированы более высокие значения пропускной способности по сравнению с поставщиком хранилища Azure по умолчанию.

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

Следующие шаги

Сведения об аварийном восстановлении и географическом распределении