Provedor de armazenamento do Azure (Azure Functions)

Este documento descreve as características do provedor de Armazenamento do Azure de Funções Duráveis, com foco em aspetos de desempenho e escalabilidade. O provedor de Armazenamento do Azure é o provedor padrão. Ele armazena estados de instância e filas em uma conta de Armazenamento do Azure (clássica).

Nota

Para obter mais informações sobre os provedores de armazenamento suportados para funções duráveis e como eles se comparam, consulte a documentação dos provedores de armazenamento de funções duráveis.

No provedor de Armazenamento do Azure, toda a execução de funções é orientada por filas de Armazenamento do Azure. A orquestração e o status e o histórico da entidade são armazenados nas Tabelas do Azure. Os Blobs do Azure e as concessões de blob são usados para distribuir instâncias e entidades de orquestração em várias instâncias de aplicativo (também conhecidas como trabalhadores ou simplesmente VMs). Esta seção entra em mais detalhes sobre os vários artefatos do Armazenamento do Azure e como eles afetam o desempenho e a escalabilidade.

Representação de armazenamento

Um hub de tarefas persiste de forma duradoura todos os estados da instância e todas as mensagens. Para obter uma visão geral rápida de como eles são usados para acompanhar o progresso de uma orquestração, consulte o exemplo de execução do hub de tarefas.

O provedor de Armazenamento do Azure representa o hub de tarefas no armazenamento usando os seguintes componentes:

• Entre duas e três Tabelas do Azure. Duas tabelas são usadas para representar históricos e estados de instância. Se o Gerenciador de Partições de Tabela estiver habilitado, uma terceira tabela será introduzida para armazenar informações de partição.
• Uma fila do Azure armazena as mensagens de atividade.
• Uma ou mais Filas do Azure armazenam as mensagens da instância. Cada uma dessas chamadas filas de controle representa uma partição à qual é atribuído um subconjunto de todas as mensagens de instância, com base no hash do ID da instância.
• Alguns contêineres de blob extras usados para blobs de leasing e/ou mensagens grandes.

Por exemplo, um hub de tarefas chamado xyz com PartitionCount = 4 contém as seguintes filas e tabelas:

Em seguida, descrevemos esses componentes e o papel que desempenham com mais detalhes.

Tabela de histórico

A tabela Histórico é uma tabela de Armazenamento do Azure que contém os eventos de histórico de todas as instâncias de orquestração em um hub de tarefas. O nome desta tabela está no formato TaskHubNameHistory. À medida que as instâncias são executadas, novas linhas são adicionadas a esta tabela. A chave de partição desta tabela é derivada do ID da instância da orquestração. As IDs de instância são aleatórias por padrão, garantindo a distribuição ideal de partições internas no Armazenamento do Azure. A chave de linha para esta tabela é um número de sequência usado para ordenar os eventos do histórico.

Quando uma instância de orquestração precisa ser executada, as linhas correspondentes da tabela History são carregadas na memória usando uma consulta de intervalo dentro de uma única partição de tabela. Esses eventos de histórico são então reproduzidos no código de função do orquestrador para recuperá-lo ao seu estado de ponto de verificação anterior. O uso do histórico de execução para reconstruir o estado dessa maneira é influenciado pelo padrão Event Sourcing.

Gorjeta

Os dados de orquestração armazenados na tabela Histórico incluem cargas úteis de saída de funções de atividade e suborquestrador. As cargas úteis de eventos externos também são armazenadas na tabela Histórico. Como o histórico completo é carregado na memória toda vez que um orquestrador precisa ser executado, um histórico grande o suficiente pode resultar em uma pressão de memória significativa em uma determinada VM. O comprimento e o tamanho do histórico de orquestração podem ser reduzidos dividindo grandes orquestrações em várias suborquestrações ou reduzindo o tamanho das saídas retornadas pela atividade e pelas funções do suborquestrador que ela chama. Como alternativa, você pode reduzir o uso de memória reduzindo os aceleradores de simultaneidade por VM para limitar quantas orquestrações são carregadas na memória simultaneamente.

Tabela de instâncias

A tabela Instances contém os status de todas as instâncias de orquestração e entidade dentro de um hub de tarefas. À medida que as instâncias são criadas, novas linhas são adicionadas a esta tabela. A chave de partição desta tabela é o ID da instância de orquestração ou a chave de entidade e a chave de linha é uma cadeia de caracteres vazia. Há uma linha por orquestração ou instância de entidade.

Esta tabela é usada para satisfazer solicitações de consulta de instância de código , bem como chamadas de API HTTP de consulta de status. É mantido eventualmente consistente com o conteúdo da tabela de História mencionada anteriormente. O uso de uma tabela de Armazenamento do Azure separada para satisfazer com eficiência as operações de consulta de instância dessa maneira é influenciado pelo padrão CQRS (Command and Query Responsibility Segregation).

Gorjeta

O particionamento da tabela Instances permite armazenar milhões de instâncias de orquestração sem qualquer impacto percetível no desempenho ou na escala do tempo de execução. No entanto, o número de instâncias pode ter um impacto significativo no desempenho da consulta de várias instâncias. Para controlar a quantidade de dados armazenados nessas tabelas, considere limpar periodicamente os dados de instâncias antigas.

Tabela de partições

Nota

Esta tabela é mostrada no hub de tarefas somente quando Table Partition Manager está habilitada. Para aplicá-lo, defina useTablePartitionManagement a configuração no host.json do seu aplicativo.

A tabela Partições armazena o status das partições para o aplicativo Funções Duráveis e é usada para distribuir partições entre os trabalhadores do seu aplicativo. Há uma linha por partição.

Queues

As funções orquestrador, entidade e atividade são acionadas por filas internas no hub de tarefas do aplicativo de função. O uso de filas dessa maneira fornece garantias confiáveis de entrega de mensagens "pelo menos uma vez". Há dois tipos de filas em Funções duráveis: a fila de controle e a fila de itens de trabalho.

A fila de itens de trabalho

Há uma fila de itens de trabalho por hub de tarefas em Funções duráveis. É uma fila básica e se comporta de forma semelhante a qualquer outra queueTrigger fila no Azure Functions. Essa fila é usada para disparar funções de atividade sem monitoração de estado, retirando uma única mensagem de cada vez. Cada uma dessas mensagens contém entradas de função de atividade e metadados adicionais, como qual função executar. Quando um aplicativo Durable Functions é expandido para várias VMs, todas essas VMs competem para adquirir tarefas da fila de itens de trabalho.

Fila(s) de controlo

Há várias filas de controle por hub de tarefas em Funções duráveis. Uma fila de controle é mais sofisticada do que a fila de itens de trabalho mais simples. As filas de controle são usadas para acionar as funções de orquestrador e entidade com monitoração de estado. Como as instâncias de função orquestrador e entidade são singletons com estado, é importante que cada orquestração ou entidade seja processada apenas por um trabalhador de cada vez. Para alcançar essa restrição, cada instância ou entidade de orquestração é atribuída a uma única fila de controle. Essas filas de controle têm balanceamento de carga entre os trabalhadores para garantir que cada fila seja processada apenas por um trabalhador de cada vez. Mais detalhes sobre esse comportamento podem ser encontrados nas seções subsequentes.

As filas de controle contêm uma variedade de tipos de mensagens do ciclo de vida da orquestração. Os exemplos incluem mensagens de controle do orquestrador, mensagens de resposta da função de atividade e mensagens de temporizador. Até 32 mensagens serão retiradas de uma fila de controle em uma única pesquisa. Essas mensagens contêm dados de carga útil, bem como metadados, incluindo a instância de orquestração a que se destina. Se várias mensagens retiradas da fila forem destinadas à mesma instância de orquestração, elas serão processadas como um lote.

As mensagens da fila de controle são constantemente pesquisadas usando um thread em segundo plano. O tamanho do lote de cada pesquisa de fila controlQueueBatchSize é controlado pela configuração no host.json e tem um padrão de 32 (o valor máximo suportado pelas Filas do Azure). O número máximo de mensagens de fila controlQueueBufferThreshold de controle pré-buscadas que são armazenadas em buffer na memória é controlado pela configuração em host.json. O valor padrão para controlQueueBufferThreshold varia dependendo de uma variedade de fatores, incluindo o tipo de plano de hospedagem. Para obter mais informações sobre essas configurações, consulte a documentação do esquema host.json.

Gorjeta

Aumentar o valor para controlQueueBufferThreshold permite que uma única orquestração ou entidade processe eventos mais rapidamente. No entanto, aumentar esse valor também pode resultar em maior uso de memória. O maior uso de memória é em parte devido a retirar mais mensagens da fila e em parte devido à busca de mais históricos de orquestração na memória. Reduzir o valor para controlQueueBufferThreshold pode, portanto, ser uma maneira eficaz de reduzir o uso de memória.

Sondagem em fila

A extensão de tarefa durável implementa um algoritmo de back-off exponencial aleatório para reduzir o efeito da sondagem de fila ociosa nos custos de transação de armazenamento. Quando uma mensagem é encontrada, o tempo de execução verifica imediatamente se há outra mensagem. Quando nenhuma mensagem é encontrada, ela aguarda um período de tempo antes de tentar novamente. Após tentativas subsequentes com falha para obter uma mensagem de fila, o tempo de espera continua a aumentar até atingir o tempo máximo de espera, que por padrão é de 30 segundos.

O atraso máximo de sondagem é configurável através da maxQueuePollingInterval propriedade no arquivo host.json. Definir essa propriedade para um valor mais alto pode resultar em latências de processamento de mensagens mais altas. Seriam esperadas latências mais elevadas apenas após períodos de inatividade. Definir essa propriedade para um valor mais baixo pode resultar em custos de armazenamento mais altos devido ao aumento das transações de armazenamento.

Nota

Ao ser executado nos planos Consumo e Premium do Azure Functions, o Controlador de Escala do Azure Functions pesquisará cada controle e fila de itens de trabalho uma vez a cada 10 segundos. Essa sondagem adicional é necessária para determinar quando ativar instâncias de aplicativo de função e tomar decisões de escala. No momento da escrita, esse intervalo de 10 segundos é constante e não pode ser configurado.

Atrasos no início da orquestração

As instâncias de orquestração são iniciadas colocando uma ExecutionStarted mensagem em uma das filas de controle do hub de tarefas. Sob certas condições, você pode observar atrasos de vários segundos entre quando uma orquestração está programada para ser executada e quando ela realmente começa a ser executada. Durante esse intervalo de tempo, a instância de orquestração permanece no Pending estado. Existem duas causas potenciais para este atraso:

• Filas de controle em atraso: Se a fila de controle para esta instância contiver um grande número de mensagens, pode levar algum tempo até que a ExecutionStarted mensagem seja recebida e processada pelo tempo de execução. As listas de pendências de mensagens podem acontecer quando as orquestrações estão processando muitos eventos simultaneamente. Os eventos que entram na fila de controle incluem eventos de início de orquestração, conclusão de atividades, temporizadores duráveis, encerramento e eventos externos. Se esse atraso acontecer em circunstâncias normais, considere a criação de um novo hub de tarefas com um número maior de partições. Configurar mais partições fará com que o tempo de execução crie mais filas de controle para distribuição de carga. Cada partição corresponde a 1:1 com uma fila de controle, com um máximo de 16 partições.

• Atrasos de sondagem de recuo: Outra causa comum de atrasos de orquestração é o comportamento de sondagem de back-off descrito anteriormente para filas de controle. No entanto, esse atraso só é esperado quando um aplicativo é expandido para duas ou mais instâncias. Se houver apenas uma instância do aplicativo ou se a instância do aplicativo que inicia a orquestração também for a mesma instância que está sondando a fila de controle de destino, não haverá um atraso na sondagem da fila. Os atrasos de sondagem podem ser reduzidos atualizando as configurações de host.json , conforme descrito anteriormente.

Blobs

Na maioria dos casos, o Durable Functions não usa Blobs de Armazenamento do Azure para persistir dados. No entanto, filas e tabelas têm limites de tamanho que podem impedir que as Funções Duráveis persistam todos os dados necessários em uma linha de armazenamento ou mensagem de fila. Por exemplo, quando uma parte dos dados que precisa ser persistida para uma fila é maior que 45 KB quando serializada, as Funções Duráveis compactam os dados e os armazenam em um blob. Ao persistir dados para armazenamento de blob dessa maneira, Durable Function armazena uma referência a esse blob na linha da tabela ou mensagem de fila. Quando o Durable Functions precisar recuperar os dados, ele os buscará automaticamente no blob. Esses blobs são armazenados no contêiner <taskhub>-largemessagesde blob.

Considerações de desempenho

As etapas extras de compactação e operação de blob para mensagens grandes podem ser caras em termos de custos de latência de CPU e E/S. Além disso, as funções duráveis precisam carregar dados persistentes na memória e podem fazer isso para muitas execuções de função diferentes ao mesmo tempo. Como resultado, a persistência de grandes cargas úteis de dados também pode causar alto uso de memória. Para minimizar a sobrecarga de memória, considere persistir cargas úteis de dados grandes manualmente (por exemplo, no armazenamento de blobs) e, em vez disso, passe referências a esses dados. Dessa forma, seu código pode carregar os dados somente quando necessário para evitar cargas redundantes durante repetições de funções do orquestrador. No entanto, o armazenamento de cargas úteis em discos locais não é recomendado, uma vez que não é garantido que o estado no disco esteja disponível, uma vez que as funções podem ser executadas em VMs diferentes ao longo de sua vida útil.

Seleção de conta de armazenamento

As filas, tabelas e blobs usados pelo Durable Functions são criados em uma conta de Armazenamento do Azure configurada. A conta a ser usada pode ser especificada usando a durableTask/storageProvider/connectionStringName configuração (ou durableTask/azureStorageConnectionStringName configuração em Durable Functions 1.x) no arquivo host.json .

Funções duráveis 2.x

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

Funções duráveis 1.x

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

Se não for especificado, a conta de armazenamento padrão AzureWebJobsStorage será usada. No entanto, para cargas de trabalho sensíveis ao desempenho, recomenda-se configurar uma conta de armazenamento não padrão. O Durable Functions usa muito o Armazenamento do Azure e usar uma conta de armazenamento dedicada isola o uso do armazenamento do Durable Functions do uso interno pelo host do Azure Functions.

Nota

As contas de Armazenamento do Azure de uso geral padrão são necessárias ao usar o provedor de Armazenamento do Azure. Não há suporte para todos os outros tipos de conta de armazenamento. É altamente recomendável usar contas de armazenamento de uso geral v1 herdadas para funções duráveis. As contas de armazenamento v2 mais recentes podem ser significativamente mais caras para cargas de trabalho do Durable Functions. Para obter mais informações sobre os tipos de conta de Armazenamento do Azure, consulte a documentação de visão geral da conta de armazenamento.

Escalonamento do orquestrador

Embora as funções de atividade possam ser dimensionadas infinitamente adicionando mais VMs de forma elástica, instâncias e entidades individuais do orquestrador são restritas a habitar uma única partição e o número máximo de partições é limitado pela partitionCount configuração em seu host.json.

Nota

De um modo geral, as funções do orquestrador destinam-se a ser leves e não devem exigir grandes quantidades de poder de computação. Portanto, não é necessário criar um grande número de partições de fila de controle para obter uma ótima taxa de transferência para orquestrações. A maior parte do trabalho pesado deve ser feito em funções de atividade sem estado, que podem ser dimensionadas infinitamente.

O número de filas de controle é definido no arquivo host.json . O trecho host.json exemplo a seguir define a durableTask/storageProvider/partitionCount propriedade (ou durableTask/partitionCount em Durable Functions 1.x) como 3. Observe que há tantas filas de controle quanto partições.

Funções duráveis 2.x

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

Funções duráveis 1.x

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

Um hub de tarefas pode ser configurado com entre 1 e 16 partições. Se não for especificado, a contagem de partições padrão será 4.

Durante cenários de baixo tráfego, seu aplicativo será dimensionado, de modo que as partições serão gerenciadas por um pequeno número de trabalhadores. Como exemplo, considere o diagrama abaixo.

No diagrama anterior, vemos que os orquestradores de 1 a 6 têm balanceamento de carga entre partições. Da mesma forma, as partições, como as atividades, têm balanceamento de carga entre os trabalhadores. As partições têm balanceamento de carga entre os trabalhadores, independentemente do número de orquestradores iniciados.

Se você estiver executando nos planos Consumo do Azure Functions ou Elastic Premium, ou se tiver o dimensionamento automático baseado em carga configurado, mais trabalhadores serão alocados à medida que o tráfego aumenta e as partições acabarão por equilibrar a carga em todos os trabalhadores. Se continuarmos a expandir, eventualmente cada partição acabará por ser gerida por um único trabalhador. As atividades, por outro lado, continuarão a ser equilibradas em todos os trabalhadores. Isso é mostrado na imagem abaixo.

O limite superior do número máximo de orquestrações ativas simultâneas em um determinado momento é igual ao número de trabalhadores alocados ao seu aplicativo vezes o valor do maxConcurrentOrchestratorFunctions. Esse limite superior pode ser tornado mais preciso quando suas partições são totalmente dimensionadas entre os trabalhadores. Quando totalmente dimensionado, e como cada trabalhador terá apenas uma única instância de host do Functions, o número máximo de instâncias simultâneas ativas do orquestrador será igual ao número de partições vezes o valor maxConcurrentOrchestratorFunctionsdo .

Nota

Neste contexto, ative significa que uma orquestração ou entidade é carregada na memória e processa novos eventos. Se a orquestração ou entidade estiver aguardando mais eventos, como o valor de retorno de uma função de atividade, ela será descarregada da memória e não será mais considerada ativa. Orquestrações e entidades serão posteriormente recarregadas na memória somente quando houver novos eventos para processar. Não há um número máximo prático de orquestrações totais ou entidades que podem ser executadas em uma única VM, mesmo que todas estejam no estado "Em execução". A única limitação é o número de instâncias de entidade ou orquestração ativas simultâneas.

A imagem abaixo ilustra um cenário totalmente dimensionado onde mais orquestradores são adicionados, mas alguns estão inativos, mostrados em cinza.

Durante a expansão, as concessões de fila de controle podem ser redistribuídas entre instâncias de host do Functions para garantir que as partições sejam distribuídas uniformemente. Essas concessões são implementadas internamente como concessões de armazenamento de Blob do Azure e garantem que qualquer instância ou entidade de orquestração individual seja executada apenas em uma única instância de host de cada vez. Se um hub de tarefas estiver configurado com três partições (e, portanto, três filas de controle), as instâncias e entidades de orquestração poderão ter balanceamento de carga em todas as três instâncias de host de retenção de locação. VMs adicionais podem ser adicionadas para aumentar a capacidade de execução da função de atividade.

O diagrama a seguir ilustra como o host do Azure Functions interage com as entidades de armazenamento em um ambiente dimensionado.

Como mostrado no diagrama anterior, todas as VMs competem por mensagens na fila de itens de trabalho. No entanto, apenas três VMs podem adquirir mensagens de filas de controle e cada VM bloqueia uma única fila de controle.

As instâncias e entidades de orquestração são distribuídas em todas as instâncias da fila de controle. A distribuição é feita por hash do ID da instância da orquestração ou do nome da entidade e do par de chaves. Os IDs de instância de orquestração por padrão são GUIDs aleatórios, garantindo que as instâncias sejam distribuídas igualmente em todas as filas de controle.

De um modo geral, as funções do orquestrador destinam-se a ser leves e não devem exigir grandes quantidades de poder de computação. Portanto, não é necessário criar um grande número de partições de fila de controle para obter uma ótima taxa de transferência para orquestrações. A maior parte do trabalho pesado deve ser feito em funções de atividade sem estado, que podem ser dimensionadas infinitamente.

Sessões prolongadas

Sessões estendidas é um mecanismo de cache que mantém orquestrações e entidades na memória mesmo depois de terminarem o processamento de mensagens. O efeito típico de habilitar sessões prolongadas é a redução da E/S em relação ao armazenamento durável subjacente e a taxa de transferência geral melhorada.

Você pode habilitar sessões estendidas definindo durableTask/extendedSessionsEnabled como true no arquivo host.json . A durableTask/extendedSessionIdleTimeoutInSeconds configuração pode ser usada para controlar por quanto tempo uma sessão ociosa será mantida na memória:

Funções 2.0

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

Funções 1.0

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

Há duas desvantagens potenciais dessa configuração a serem observadas:

1. Há um aumento geral no uso da memória do aplicativo de função porque as instâncias ociosas não são descarregadas da memória tão rapidamente.
2. Pode haver uma diminuição geral na taxa de transferência se houver muitas execuções simultâneas, distintas e de curta duração de orquestrador ou função de entidade.

Por exemplo, se durableTask/extendedSessionIdleTimeoutInSeconds estiver definido como 30 segundos, um episódio de orquestrador ou função de entidade de curta duração que seja executado em menos de 1 segundo ainda ocupa a memória por 30 segundos. Ele também conta contra a cota durableTask/maxConcurrentOrchestratorFunctions mencionada anteriormente, potencialmente impedindo que outras funções de orquestrador ou entidade sejam executadas.

Os efeitos específicos das sessões prolongadas nas funções de orquestrador e entidade são descritos nas próximas seções.

Nota

Atualmente, as sessões estendidas são suportadas apenas em linguagens .NET, como C# ou F#. A configuração extendedSessionsEnabled para true outras plataformas pode levar a problemas de tempo de execução, como falha silenciosa na execução de atividades e funções acionadas por orquestração.

Replay da função Orchestrator

Como mencionado anteriormente, as funções do orquestrador são repetidas usando o conteúdo da tabela Histórico . Por padrão, o código da função orchestrator é repetido sempre que um lote de mensagens é retirado da fila de controle. Mesmo se você estiver usando o padrão de fan-out, fan-in e estiver aguardando a conclusão de todas as tarefas (por exemplo, usando Task.WhenAll() em .NET, context.df.Task.all() em JavaScript ou context.task_all() em Python), haverá repetições que ocorrerão à medida que lotes de respostas de tarefas forem processados ao longo do tempo. Quando as sessões estendidas são habilitadas, as instâncias da função orchestrator são mantidas na memória por mais tempo e novas mensagens podem ser processadas sem uma reprodução completa do histórico.

A melhoria do desempenho de sessões prolongadas é mais frequentemente observada nas seguintes situações:

• Quando há um número limitado de instâncias de orquestração em execução simultânea.
• Quando as orquestrações têm um grande número de ações sequenciais (por exemplo, centenas de chamadas de função de atividade) que são concluídas rapidamente.
• Quando as orquestrações se espalham e se espalham por um grande número de ações que se completam ao mesmo tempo.
• Quando as funções do orquestrador precisam processar mensagens grandes ou fazer qualquer processamento de dados com uso intensivo de CPU.

Em todas as outras situações, normalmente não há melhoria de desempenho observável para funções de orquestrador.

Nota

Essas configurações só devem ser usadas depois que uma função do orquestrador tiver sido totalmente desenvolvida e testada. O comportamento de repetição agressivo padrão pode ser útil para detetar violações de restrições de código de função do orquestrador no momento do desenvolvimento e, portanto, é desativado por padrão.

Objetivos de desempenho

A tabela a seguir mostra os números de taxa de transferência máxima esperados para os cenários descritos na seção Metas de desempenho do artigo Desempenho e escala.

"Instância" refere-se a uma única instância de uma função orquestradora em execução em uma única VM pequena (A1) no Serviço de Aplicativo do Azure. Em todos os casos, presume-se que as sessões estendidas estão habilitadas. Os resultados reais podem variar dependendo da CPU ou do trabalho de E/S realizado pelo código da função.

Cenário	Débito máximo
Execução sequencial da atividade	5 atividades por segundo, por instância
Execução de atividade paralela (fan-out)	100 atividades por segundo, por instância
Processamento de resposta paralela (fan-in)	150 respostas por segundo, por instância
Processamento de eventos externos	50 eventos por segundo, por instância
Processamento da operação da entidade	64 operações por segundo

Se você não estiver vendo os números de taxa de transferência esperados e o uso da CPU e da memória parecerem íntegros, verifique se a causa está relacionada à integridade da sua conta de armazenamento. A extensão Durable Functions pode colocar uma carga significativa em uma conta de Armazenamento do Azure e cargas suficientemente altas podem resultar na limitação da conta de armazenamento.

Gorjeta

Em alguns casos, você pode aumentar significativamente a taxa de transferência de eventos externos, fan-in de atividade e operações de entidade aumentando o valor da controlQueueBufferThreshold configuração em host.json. Aumentar esse valor além de seu padrão faz com que o provedor de armazenamento do Durable Task Framework use mais memória para pré-buscar esses eventos de forma mais agressiva, reduzindo os atrasos associados à retirada de mensagens da fila de controle do Armazenamento do Azure. Para obter mais informações, consulte a documentação de referência host.json.

Processamento de alto rendimento

A arquitetura do back-end do Armazenamento do Azure coloca certas limitações no desempenho teórico máximo e na escalabilidade das Funções Duráveis. Se o teste mostrar que as Funções Duráveis no Armazenamento do Azure não atenderão aos seus requisitos de taxa de transferência, você deve considerar o uso do provedor de armazenamento Netherite para Funções Duráveis.

Para comparar a taxa de transferência alcançável para vários cenários básicos, consulte a seção Cenários básicos da documentação do provedor de armazenamento Netherite.

O back-end de armazenamento Netherite foi projetado e desenvolvido pela Microsoft Research. Ele usa os Hubs de Eventos do Azure e a tecnologia de banco de dados FASTER sobre os Blobs de Página do Azure. O design da Netherite permite um processamento significativamente mais alto de orquestrações e entidades em comparação com outros provedores. Em alguns cenários de referência, a taxa de transferência aumentou em mais de uma ordem de magnitude quando comparada ao provedor de Armazenamento do Azure padrão.

Para obter mais informações sobre os provedores de armazenamento suportados para funções duráveis e como eles se comparam, consulte a documentação dos provedores de armazenamento de funções duráveis.

Próximos passos

Saiba mais sobre recuperação de desastres e distribuição geográfica