Fornecedor de Armazenamento do Azure (Funções do Azure)
Este documento descreve as características do Durable Functions fornecedor de Armazenamento do Azure, com foco nos aspetos de desempenho e escalabilidade. O fornecedor de Armazenamento do Azure é o fornecedor predefinido. Armazena estados de instância e filas numa conta do Armazenamento do Azure (clássico).
Nota
Para obter mais informações sobre os fornecedores de armazenamento suportados para Durable Functions e como se comparam, veja a documentação Durable Functions fornecedores de armazenamento.
No fornecedor de Armazenamento do Azure, toda a execução de funções é condicionada por filas de Armazenamento do Azure. A orquestração e o estado e o histórico de entidades são armazenados nas Tabelas do Azure. Os Blobs do Azure e as concessões de blobs são utilizados para distribuir instâncias de orquestração e entidades por várias instâncias de aplicações (também conhecidas como funções de trabalho ou simplesmente VMs). Esta secção aborda mais detalhadamente os vários artefactos do Armazenamento do Azure e como afetam o desempenho e a escalabilidade.
Representação do armazenamento
Um hub de tarefas persiste duravelmente em todos os estados de instância e todas as mensagens. Para obter uma descrição geral rápida de como estas são utilizadas para acompanhar o progresso de uma orquestração, veja o exemplo de execução do hub de tarefas.
O fornecedor de Armazenamento do Azure representa o hub de tarefas no armazenamento com os seguintes componentes:
- Entre duas e três Tabelas do Azure. São utilizadas duas tabelas para representar históricos e estados de instância. Se o Gestor de Partições de Tabela estiver ativado, será introduzida uma terceira tabela 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 destas chamadas filas de controlo 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 contentores de blobs adicionais utilizados para blobs de concessão e/ou mensagens grandes.
Por exemplo, um hub de tarefas com PartitionCount = 4 o nome xyz contém as seguintes filas e tabelas:
Em seguida, descrevemos estes componentes e a função que desempenham mais detalhadamente.
Tabela histórico
A tabela Histórico é uma tabela do Armazenamento do Azure que contém os eventos do histórico para todas as instâncias de orquestração num hub de tarefas. O nome desta tabela está no formulário Histórico do TaskHubName. À medida que as instâncias são executadas, são adicionadas novas linhas a esta tabela. A chave de partição desta tabela é derivada do ID de instância da orquestração. Os IDs de instância são aleatórios por predefinição, garantindo uma distribuição ideal das partições internas no Armazenamento do Azure. A chave de linha para esta tabela é um número de sequência utilizado para ordenar os eventos do histórico.
Quando uma instância de orquestração tem de ser executada, as linhas correspondentes da tabela Histórico são carregadas para a memória através de uma consulta de intervalo numa única partição de tabela. Estes eventos do histórico são, em seguida, reproduzidos no código da função do orquestrador para o colocar novamente no estado de ponto de verificação anterior. A utilização do histórico de execuções para reconstruir o estado desta forma é influenciada pelo padrão de Origem do Evento.
Dica
Os dados de orquestração armazenados na tabela Histórico incluem payloads de saída de atividades e funções de sub-orquestrador. Os payloads de eventos externos também são armazenados na tabela Histórico. Uma vez que o histórico completo é carregado na memória sempre que um orquestrador precisa de ser executado, um histórico suficientemente grande pode resultar numa pressão de memória significativa numa determinada VM. O comprimento e o tamanho do histórico de orquestração podem ser reduzidos ao dividir orquestrações grandes em múltiplas sub-orquestrações ou ao reduzir o tamanho das saídas devolvidas pela atividade e pelas funções de sub-orquestrador a que chama. Em alternativa, pode reduzir a utilização da memória ao reduzir as limitações de simultaneidade por VM para limitar o número de orquestrações que são carregadas para a memória em simultâneo.
Tabela Instâncias
A tabela Instâncias contém os estados de todas as instâncias de orquestração e entidade num hub de tarefas. À medida que as instâncias são criadas, são adicionadas novas linhas 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 vazia. Existe uma linha por orquestração ou instância de entidade.
Esta tabela é utilizada para satisfazer pedidos de consulta de instâncias de código , bem como chamadas à API HTTP da consulta de estado . É mantido, eventualmente, consistente com os conteúdos da tabela Histórico mencionados anteriormente. A utilização de uma tabela do Armazenamento do Azure separada para satisfazer eficazmente as operações de consulta de instâncias desta forma é influenciada pelo padrão de Segregação de Responsabilidade de Comandos e Consultas (CQRS).
Dica
A criação de partições da tabela Instances permite-lhe armazenar milhões de instâncias de orquestração sem qualquer impacto notável no desempenho ou dimensionamento do runtime. No entanto, o número de instâncias pode ter um impacto significativo no desempenho de consultas de várias instâncias . Para controlar a quantidade de dados armazenados nestas tabelas, considere remover periodicamente dados de instâncias antigas.
Tabela partições
Nota
Esta tabela só é apresentada no hub de tarefas quando Table Partition Manager está ativada. Para aplicá-la, configure useTablePartitionManagement a definição no host.json da sua aplicação.
A tabela Partições armazena o estado das partições da aplicação Durable Functions e é utilizada para distribuir partições pelos trabalhos da sua aplicação. Existe uma linha por partição.
Filas
As funções orchestrator, entidade e atividade são acionadas por filas internas no hub de tarefas da aplicação de funções. A utilização de filas desta forma fornece garantias fiáveis de entrega de mensagens "pelo menos uma vez". Existem dois tipos de filas no Durable Functions: a fila de controlo e a fila do item de trabalho.
A fila do item de trabalho
Existe uma fila de item de trabalho por hub de tarefas no Durable Functions. É uma fila básica e comporta-se de forma semelhante a qualquer outra queueTrigger fila no Funções do Azure. Esta fila é utilizada para acionar funções de atividade sem estado ao desativar uma única mensagem de cada vez. Cada uma destas mensagens contém entradas de função de atividade e metadados adicionais, como a função a executar. Quando uma aplicação Durable Functions dimensiona horizontalmente para várias VMs, todas estas VMs competem para adquirir tarefas a partir da fila de itens de trabalho.
Filas de controlo
Existem várias filas de controlo por hub de tarefas no Durable Functions. Uma fila de controlo é mais sofisticada do que a fila de itens de trabalho mais simples. As filas de controlo são utilizadas para acionar o orquestrador com estado e as funções de entidade. Uma vez que as instâncias do orquestrador e da função de entidade são singletons com monitorização de estado, é importante que cada orquestração ou entidade seja processada apenas por uma função de trabalho de cada vez. Para alcançar esta restrição, cada instância ou entidade de orquestração é atribuída a uma única fila de controlo. Estas filas de controlo são balanceadas de carga entre as funções de trabalho para garantir que cada fila é processada apenas por uma função de trabalho de cada vez. Pode encontrar mais detalhes sobre este comportamento nas secções subsequentes.
As filas de controlo contêm uma variedade de tipos de mensagens de ciclo de vida de orquestração. Os exemplos incluem mensagens de controlo do orchestrator, mensagens de resposta da função de atividade e mensagens de temporizador. Até 32 mensagens serão retiradas da fila de controlo numa única sondagem. Estas mensagens contêm dados de payload, bem como metadados, incluindo a instância de orquestração para a qual se destina. Se várias mensagens em fila forem destinadas à mesma instância de orquestração, serão processadas como um lote.
As mensagens de fila de controlo são constantemente consultadas através de um thread de fundo. O tamanho do lote de cada inquérito de fila é controlado pela controlQueueBatchSize definição em host.json e tem uma predefinição de 32 (o valor máximo suportado pelas Filas do Azure). O número máximo de mensagens de fila de controlo pré-selecionadas que estão na memória intermédia é controlado pela controlQueueBufferThreshold definição em host.json. O valor predefinido para controlQueueBufferThreshold varia consoante uma variedade de fatores, incluindo o tipo de plano de alojamento. Para obter mais informações sobre estas definições, veja a documentação do esquema host.json .
Dica
Aumentar o valor de controlQueueBufferThreshold permite que uma única orquestração ou entidade processe eventos mais rapidamente. No entanto, aumentar este valor também pode resultar numa utilização de memória mais elevada. O aumento da utilização da memória deve-se, em parte, à retirada de mais mensagens da fila e, em parte, à obtenção de mais históricos de orquestração na memória. Reduzir o valor de controlQueueBufferThreshold pode, portanto, ser uma forma eficaz de reduzir a utilização da memória.
Consulta de fila
A extensão de tarefa durável implementa um algoritmo de ativação exponencial aleatório para reduzir o efeito da consulta de fila de inatividade nos custos de transação de armazenamento. Quando é encontrada uma mensagem, o runtime verifica imediatamente a existência de outra mensagem. Quando não é encontrada nenhuma mensagem, aguarda um período de tempo antes de tentar novamente. Após tentativas falhadas subsequentes de obter uma mensagem de fila, o tempo de espera continua a aumentar até atingir o tempo máximo de espera, que é predefinido para 30 segundos.
O atraso máximo da consulta é configurável através da maxQueuePollingInterval propriedade no ficheiro host.json. Definir esta propriedade para um valor mais elevado pode resultar em latências de processamento de mensagens mais elevadas. As latências mais elevadas só seriam esperadas após períodos de inatividade. Definir esta propriedade para um valor mais baixo pode resultar em custos de armazenamento mais elevados devido ao aumento das transações de armazenamento.
Nota
Ao executar nos planos consumo Funções do Azure e Premium, o Controlador de Escala Funções do Azure irá consultar cada controlo e fila de itens de trabalho uma vez a cada 10 segundos. Esta consulta adicional é necessária para determinar quando ativar instâncias da aplicação de funções e tomar decisões de dimensionamento. No momento da escrita, este intervalo de 10 segundos é constante e não pode ser configurado.
Atrasos no início da orquestração
As instâncias de orquestrações são iniciadas ao colocar uma mensagem numa ExecutionStarted das filas de controlo do hub de tarefas. Em determinadas condições, poderá observar atrasos de vários segundos entre a execução de uma orquestração e a execução da mesma. Durante este intervalo de tempo, a instância de orquestração permanece no Pending estado . Existem duas causas potenciais deste atraso:
Filas de controlo com registo de tarefas pendentes: se a fila de controlo para esta instância contiver um grande número de mensagens, poderá demorar algum tempo até a
ExecutionStartedmensagem ser recebida e processada pelo runtime. Os registos de tarefas pendentes de mensagens podem ocorrer quando as orquestrações estão a processar muitos eventos em simultâneo. Os eventos que entram na fila de controlo incluem eventos de início de orquestração, conclusões de atividade, temporizadores duráveis, terminação e eventos externos. Se este atraso ocorrer em circunstâncias normais, considere criar um novo hub de tarefas com um maior número de partições. A configuração de mais partições fará com que o runtime crie mais filas de controlo para distribuição de carga. Cada partição corresponde a 1:1 com uma fila de controlo, com um máximo de 16 partições.Recuar nos atrasos nas consultas: outra causa comum de atrasos de orquestração é o comportamento de consulta de recuo descrito anteriormente para filas de controlo. No entanto, este atraso só é esperado quando uma aplicação é aumentada horizontalmente para duas ou mais instâncias. Se existir apenas uma instância de aplicação ou se a instância da aplicação que inicia a orquestração for também a mesma instância que está a consultar a fila de controlo de destino, não haverá um atraso na consulta da fila. Os atrasos nas consultas podem ser reduzidos ao atualizar as definições host.json , conforme descrito anteriormente.
Blobs
Na maioria dos casos, Durable Functions não utiliza Blobs de Armazenamento do Azure para manter os dados. No entanto, as filas e as tabelas têm limites de tamanho que podem impedir Durable Functions de manter todos os dados necessários numa linha de armazenamento ou numa mensagem de fila. Por exemplo, quando uma parte dos dados que precisa de ser persistente numa fila é superior a 45 KB quando serializada, Durable Functions irá comprimir os dados e armazená-lo num blob. Ao manter os dados no armazenamento de blobs desta forma, a Durable Function armazena uma referência a esse blob na mensagem de fila ou linha da tabela. Quando Durable Functions precisar de obter os dados, irá obtê-lo automaticamente a partir do blob. Estes blobs são armazenados no contentor de blobs <taskhub>-largemessages.
Considerações de desempenho
Os passos adicionais de compressão e operação de blobs para mensagens grandes podem ser dispendiosos em termos de custos de latência de CPU e E/S. Além disso, Durable Functions precisa de carregar dados persistentes na memória e pode fazê-lo para muitas execuções de funções diferentes ao mesmo tempo. Como resultado, a persistência de payloads de dados grandes também pode causar uma utilização elevada da memória. Para minimizar a sobrecarga da memória, considere manter manualmente grandes payloads de dados (por exemplo, no armazenamento de blobs) e, em vez disso, transmitir referências a estes dados. Desta forma, o código só pode carregar os dados quando necessário para evitar cargas redundantes durante as repetições de funções do orchestrator. No entanto, o armazenamento de payloads 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 das suas durações.
Seleção da conta de armazenamento
As filas, tabelas e blobs utilizados pelo Durable Functions são criados numa conta de Armazenamento do Azure configurada. A conta a utilizar pode ser especificada com a durableTask/storageProvider/connectionStringName definição (ou durableTask/azureStorageConnectionStringName definição no Durable Functions 1.x) no ficheiro host.json.
Durable Functions 2.x
{
"extensions": {
"durableTask": {
"storageProvider": {
"connectionStringName": "MyStorageAccountAppSetting"
}
}
}
}
Durable Functions 1.x
{
"extensions": {
"durableTask": {
"azureStorageConnectionStringName": "MyStorageAccountAppSetting"
}
}
}
Se não for especificado, é utilizada a conta de armazenamento predefinida AzureWebJobsStorage . No entanto, para cargas de trabalho sensíveis ao desempenho, recomenda-se configurar uma conta de armazenamento não predefinida. Durable Functions utiliza bastante o Armazenamento do Azure e a utilização de uma conta de armazenamento dedicada isola Durable Functions utilização de armazenamento da utilização interna pelo anfitrião Funções do Azure.
Nota
São necessárias contas de Armazenamento do Azure para fins gerais padrão ao utilizar o fornecedor de Armazenamento do Azure. Todos os outros tipos de contas de armazenamento não são suportados. Recomendamos vivamente a utilização de contas de armazenamento para fins gerais v1 legadas para Durable Functions. As contas de armazenamento v2 mais recentes podem ser significativamente mais caras para Durable Functions cargas de trabalho. Para obter mais informações sobre os tipos de contas de Armazenamento do Azure, veja a Documentação de descrição geral da conta de armazenamento .
Escalamento horizontal do Orchestrator
Embora as funções de atividade possam ser aumentadas horizontalmente infinitamente ao adicionar mais VMs de forma elástica, as instâncias e entidades do orquestrador individual estão limitadas a habitar uma única partição e o número máximo de partições está vinculado pela partitionCount definição no .host.json
Nota
De um modo geral, as funções de orquestrador destinam-se a ser leves e não devem exigir grandes quantidades de poder de computação. Por conseguinte, não é necessário criar um grande número de partições de fila de controlo para obter um excelente débito para orquestrações. A maior parte do trabalho pesado deve ser feito em funções de atividade sem estado, que podem ser aumentados horizontalmente infinitamente.
O número de filas de controlo é definido no ficheiro host.json . O fragmento host.json de exemplo seguinte define a durableTask/storageProvider/partitionCount propriedade (ou durableTask/partitionCount em Durable Functions 1.x) como 3. Tenha em atenção que existem tantas filas de controlo como as partições.
Durable Functions 2.x
{
"extensions": {
"durableTask": {
"storageProvider": {
"partitionCount": 3
}
}
}
}
Durable Functions 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 predefinida é 4.
Durante os cenários de tráfego reduzido, a aplicação será reduzida horizontalmente, pelo que as partições serão geridas por um pequeno número de trabalhadores. Por exemplo, considere o diagrama abaixo.
No diagrama anterior, vemos que os orquestradores 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 as funções de trabalho. As partições têm balanceamento de carga entre as funções de trabalho, independentemente do número de orquestradores que são iniciados.
Se estiver a executar os planos de Consumo Funções do Azure ou Elastic Premium ou se tiver o dimensionamento automático baseado na carga configurado, mais trabalhadores serão alocados à medida que o tráfego aumenta e as partições acabarão por ser balanceadas de carga em todos os trabalhos. Se continuarmos a aumentar horizontalmente, eventualmente cada partição será eventualmente gerida por uma única função de trabalho. Por outro lado, as actividades continuarão a ter balanceamento de carga em todos os trabalhadores. Isto é apresentado na imagem abaixo.
O limite superior do número máximo de orquestrações ativas simultâneas em qualquer momento é igual ao número de trabalhadores alocados à sua aplicação vezes o valor de maxConcurrentOrchestratorFunctions. Este limite superior pode tornar-se mais preciso quando as partições são totalmente reduzidas horizontalmente entre as funções de trabalho. Quando totalmente aumentado horizontalmente, e uma vez que cada função de trabalho terá apenas uma única instância de anfitrião de Funções, o número máximo de instâncias de orquestrador simultâneas ativas será igual ao seu número de partições vezes o seu valor para maxConcurrentOrchestratorFunctions.
Nota
Neste contexto, ativo significa que uma orquestração ou entidade é carregada na memória e a processar novos eventos. Se a orquestração ou entidade estiver à espera de mais eventos, como o valor devolvido de uma função de atividade, é descarregada da memória e já não é considerada ativa. Posteriormente, as orquestrações e entidades serão recarregadas para a memória apenas quando existirem novos eventos a processar. Não existe um número máximo prático de orquestrações ou entidades totais que possam ser executadas numa única VM, mesmo que estejam todas no estado "Em execução". A única limitação é o número de instâncias de orquestração ou entidade em simultâneo ativas .
A imagem abaixo ilustra um cenário totalmente aumentado horizontalmente onde são adicionados mais orquestradores, mas alguns estão inativos, mostrados a cinzento.
Durante o aumento horizontal, as concessões de filas de controlo podem ser redistribuídas pelas instâncias de anfitrião de Funções para garantir que as partições são distribuídas uniformemente. Estas concessões são implementadas internamente como concessões de armazenamento de Blobs do Azure e garantem que qualquer instância ou entidade de orquestração individual só é executada numa única instância de anfitrião de cada vez. Se um hub de tarefas estiver configurado com três partições (e, portanto, três filas de controlo), as instâncias de orquestração e as entidades podem ser balanceadas de carga em todas as três instâncias de anfitrião de concessão. Podem ser adicionadas VMs adicionais para aumentar a capacidade de execução da função de atividade.
O diagrama seguinte ilustra como o Funções do Azure anfitrião interage com as entidades de armazenamento num ambiente aumentado horizontalmente.
Conforme mostrado no diagrama anterior, todas as VMs competem por mensagens na fila do item de trabalho. No entanto, apenas três VMs podem adquirir mensagens de filas de controlo e cada VM bloqueia uma única fila de controlo.
As instâncias e entidades de orquestração são distribuídas por todas as instâncias de fila de controlo. A distribuição é feita através do hash do ID da instância da orquestração ou do nome da entidade e do par de chaves. Por predefinição, os IDs da instância de orquestração são GUIDs aleatórios, garantindo que as instâncias são distribuídas de forma igual em todas as filas de controlo.
De um modo geral, as funções de orquestrador destinam-se a ser leves e não devem exigir grandes quantidades de poder de computação. Por conseguinte, não é necessário criar um grande número de partições de fila de controlo para obter um excelente débito para orquestrações. A maior parte do trabalho pesado deve ser feito em funções de atividade sem estado, que podem ser aumentados horizontalmente infinitamente.
Sessões prolongadas
As sessões prolongadas são um mecanismo de colocação em cache que mantém orquestrações e entidades na memória mesmo depois de terminarem o processamento de mensagens. O efeito típico da ativação de sessões prolongadas é a redução da E/S face ao arquivo durável subjacente e ao débito global melhorado.
Pode ativar sessões expandidas ao definir durableTask/extendedSessionsEnabled como true no ficheiro host.json . A durableTask/extendedSessionIdleTimeoutInSeconds definição pode ser utilizada para controlar durante quanto tempo será realizada uma sessão inativa na memória:
Funções 2.0
{
"extensions": {
"durableTask": {
"extendedSessionsEnabled": true,
"extendedSessionIdleTimeoutInSeconds": 30
}
}
}
Funções 1.0
{
"durableTask": {
"extendedSessionsEnabled": true,
"extendedSessionIdleTimeoutInSeconds": 30
}
}
Existem duas potenciais desvantagens desta definição a ter em conta:
- Existe um aumento geral na utilização da memória da aplicação de funções porque as instâncias inativas não são descarregadas da memória tão rapidamente.
- Pode haver uma diminuição geral do débito se existirem muitas execuções simultâneas, distintas e de curta duração do orquestrador ou da função de entidade.
Por exemplo, se durableTask/extendedSessionIdleTimeoutInSeconds estiver definido como 30 segundos, um orquestrador de curta duração ou episódio de função de entidade que é executado em menos de 1 segundo ainda ocupa a memória durante 30 segundos. Também conta com a durableTask/maxConcurrentOrchestratorFunctions quota mencionada anteriormente, o que pode impedir a execução de outras funções de orquestrador ou entidade.
Os efeitos específicos das sessões alargadas no orquestrador e nas funções de entidade são descritos nas secções seguintes.
Nota
Atualmente, as sessões alargadas só são suportadas em idiomas .NET, como C# ou F#. Definir extendedSessionsEnabled para true para outras plataformas pode levar a problemas de runtime, tais como falha silenciosa na execução de atividades e funções acionadas por orquestração.
Repetição da função do Orchestrator
Conforme mencionado anteriormente, as funções do orquestrador são reproduzidas com o conteúdo da tabela Histórico . Por predefinição, o código da função do orquestrador é reproduzido sempre que um lote de mensagens é desativado de uma fila de controlo. Mesmo que esteja a utilizar o padrão fan-out e fan-in e esteja à espera que todas as tarefas sejam concluídas (por exemplo, utilizando Task.WhenAll() no .NET, context.df.Task.all() em JavaScript ou context.task_all() em Python), haverá repetições que ocorrem à medida que os lotes de respostas de tarefas são processados ao longo do tempo. Quando as sessões prolongadas são ativadas, as instâncias da função do orquestrador são mantidas na memória por mais tempo e as novas mensagens podem ser processadas sem uma repetição completa do histórico.
A melhoria do desempenho das sessões prolongadas é observada mais frequentemente nas seguintes situações:
- Quando existe um número limitado de instâncias de orquestração em execução em simultâneo.
- 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 são fan-out e fan-in um grande número de ações que são concluídas ao mesmo tempo.
- Quando as funções do orquestrador precisam de processar mensagens grandes ou de fazer qualquer processamento de dados com utilização intensiva da CPU.
Em todas as outras situações, normalmente não há melhorias de desempenho observáveis para as funções do orquestrador.
Nota
Estas definições só devem ser utilizadas depois de uma função de orquestrador ter sido totalmente desenvolvida e testada. O comportamento de repetição agressiva predefinido pode ser útil para detetar violações de restrições de código de função do orquestrador no momento do desenvolvimento e, por conseguinte, está desativado por predefinição.
Destinos de desempenho
A tabela seguinte mostra os números máximos de débito esperados para os cenários descritos na secção Destinos de Desempenho do artigo Desempenho e Escala .
"Instância" refere-se a uma única instância de uma função de orquestrador em execução numa única VM pequena (A1) no Serviço de Aplicações do Azure. Em todos os casos, presume-se que as sessões prolongadas estão ativadas. Os resultados reais podem variar consoante o trabalho de CPU ou E/S efetuado pelo código de função.
| Scenario | Débito máximo |
|---|---|
| Execução de atividade sequencial | 5 atividades por segundo, por instância |
| Execução de atividade paralela (fan-out) | 100 atividades por segundo, por instância |
| Processamento de resposta paralelo (fan-in) | 150 respostas por segundo, por instância |
| Processamento de eventos externos | 50 eventos por segundo, por instância |
| Processamento da operação de entidade | 64 operações por segundo |
Se não estiver a ver os números de débito esperados e a utilização da CPU e da memória parecer em bom estado de funcionamento, verifique se a causa está relacionada com o estado de funcionamento da sua conta de armazenamento. A extensão Durable Functions pode colocar carga significativa numa conta de Armazenamento do Azure e cargas suficientemente elevadas podem resultar na limitação da conta de armazenamento.
Dica
Em alguns casos, pode aumentar significativamente o débito de eventos externos, fan-in de atividade e operações de entidade ao aumentar o valor da controlQueueBufferThreshold definição em host.json. Aumentar este valor para além da predefinição faz com que o fornecedor de armazenamento da Durable Task Framework utilize mais memória para pré-executar estes eventos de forma mais agressiva, reduzindo os atrasos associados à desaconsultação de mensagens das filas de controlo do Armazenamento do Azure. Para obter mais informações, veja a documentação de referência host.json .
Processamento de débito elevado
A arquitetura do back-end do Armazenamento do Azure coloca determinadas limitações no desempenho teórico máximo e na escalabilidade de Durable Functions. Se os testes mostrarem que Durable Functions no Armazenamento do Azure não cumprirão os seus requisitos de débito, deve considerar utilizar o fornecedor de armazenamento Netherite para Durable Functions.
Para comparar o débito alcançável para vários cenários básicos, veja a secção Cenários Básicos da documentação do fornecedor de armazenamento Netherite.
O back-end de armazenamento Netherite foi concebido e desenvolvido pela Microsoft Research. Utiliza Hubs de Eventos do Azure e a tecnologia de base de dados MAIS RÁPIDA sobre os Blobs de Páginas do Azure. A conceção do Netherite permite um processamento de débito significativamente maior de orquestrações e entidades em comparação com outros fornecedores. Em alguns cenários de referência, o débito foi mostrado para aumentar em mais do que uma ordem de magnitude em comparação com o fornecedor de Armazenamento do Azure predefinido.
Para obter mais informações sobre os fornecedores de armazenamento suportados para Durable Functions e como se comparam, veja a documentação Durable Functions fornecedores de armazenamento.