Partilhar via

Diagnosticar e resolver exceções de tempo limite de pedidos do SDK .NET do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

O erro HTTP 408 ocorrerá se o SDK não conseguir concluir o pedido antes de o tempo limite ser atingido.

É importante certificar-se de que o design do aplicativo está seguindo nosso guia para projetar aplicativos resilientes com SDKs do Azure Cosmos DB para garantir que ele reaja corretamente a diferentes condições de rede. A aplicação deverá ter a política de repetição em vigor para os erros de tempo limite, uma vez que estes são normalmente esperados num sistema distribuído.

Ao avaliar o caso de erros de tempo limite:

  • Qual é o impacto medido no volume de operações afetadas em comparação com as operações que têm sucesso? Está dentro dos SLAs de serviço?
  • A latência/disponibilidade do P99 é afetada?
  • As falhas estão a afetar todas as instâncias de aplicação ou apenas um subconjunto? Quando o problema é reduzido a um subconjunto de instâncias,geralmente, trata-se de um problema relacionado com essas instâncias.

Personalizar o tempo limite no SDK .NET do Azure Cosmos DB

O SDK tem duas alternativas distintas para controlar tempos limites, cada uma com um escopo diferente.

Tempos limite de nível de solicitação

A CosmosClientOptions.RequestTimeout configuração (ou ConnectionPolicy.RequestTimeout para SDK v2) permite definir um tempo limite para a solicitação de rede depois que a solicitação saiu do SDK e está na rede, até que uma resposta seja recebida.

A CosmosClientOptions.OpenTcpConnectionTimeout configuração (ou ConnectionPolicy.OpenTcpConnectionTimeout para SDK v2) permite definir um tempo limite para o tempo gasto na abertura de uma conexão inicial. Assim que uma conexão for aberta, as solicitações subsequentes usarão a conexão.

Uma operação iniciada por um usuário pode abranger várias solicitações de rede, por exemplo, tentativas. Essas duas configurações são por solicitação, não de ponta a ponta para uma operação.

CancellationToken

Todas as operações assíncronas no SDK têm um parâmetro opcional CancellationToken. Esse parâmetro CancellationToken é usado durante toda a operação, em todas as solicitações e tentativas de rede. Entre os pedidos de rede, o token de cancelamento poderá ser verificado e uma operação cancelada se o token relacionado estiver expirado. O token de cancelamento deve ser utilizado para definir um tempo limite esperado aproximado no âmbito da operação.

Nota

O CancellationToken parâmetro é um mecanismo em que a biblioteca verificará o cancelamento quando ele não causar um estado inválido. A operação pode não ser cancelada exatamente quando terminar o tempo definido no cancelamento. Em vez disso, depois de terminar o tempo, é cancelada quando for seguro fazê-lo.

Passos de resolução de problemas

A lista seguinte contém causas e soluções conhecidas para exceções de tempo limite de pedidos.

CosmosOperationCanceledException

Este tipo de exceção é comum quando a sua aplicação está a transmitir CancellationTokens para as operações do SDK. O SDK verifica o estado das CancellationToken tentativas intermediárias e, se a CancellationToken for cancelada, anulará a operação atual com essa exceção.

A exceção Message / ToString() também indicará o estado do seu CancellationToken através Cancellation Token has expired: true , e também conterá Diagnósticos que contêm o contexto do cancelamento para as solicitações envolvidas.

Essas exceções são seguras para novas tentativas e podem ser tratadas como tempos limite da perspetiva de novas tentativas.

Solução

Verifique o tempo configurado no seu CancellationToken, certifique-se de que é maior do que o seu RequestTimeout e o CosmosClientOptions.OpenTcpConnectionTimeout (se estiver a utilizar o modo Direct). Se o tempo disponível no CancellationToken for menor do que os tempos limite configurados e o SDK estiver enfrentando problemas transitórios de conectividade, o SDK não poderá tentar novamente e lançará CosmosOperationCanceledException.

Utilização elevada da CPU

A utilização elevada da CPU é o caso mais comum. Para a latência ideal, a utilização da CPU deve ser de aproximadamente 40%. Utilize 10 segundos como intervalo para monitorizar a utilização máxima (não média) da CPU. Os picos de CPU são mais comuns com consultas entre partições em que pode fazer múltiplas ligações para uma única consulta.

Os tempos limite conterão Diagnósticos, que conterão:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Se os valores forem superiores a cpu 70%, é provável que o tempo limite seja causado pela exaustão da CPU. Neste caso, a solução consiste em investigar a origem da utilização elevada da CPU e reduzi-la ou dimensionar o computador para um tamanho de recurso maior.
  • Se os threadInfo/isThreadStarving nós tiverem True valores, a causa é a fome de thread. Neste caso, a solução consiste em investigar as origens da privação de threads (threads potencialmente bloqueados) ou dimensionar os computadores para um tamanho de recurso maior.
  • Se o dateUtc tempo entre as medições não for de aproximadamente 10 segundos, isso também indicaria contenção no pool de threads. A CPU é medida como uma Tarefa independente que é colocada em fila no conjunto de threads a cada 10 segundos. Se o tempo entre medições for maior, significa que as Tarefas assíncronas não podem ser processadas em tempo útil. Os cenários mais comuns ocorrem ao fazer chamadas de bloqueio através de código assíncrono no código da aplicação.

Solução

A aplicação cliente que utiliza o SDK deve ser aumentada vertical ou horizontalmente.

A disponibilidade do socket ou da porta pode ser baixa

Ao executar no Azure, os clientes que utilizam o SDK .NET podem atingir a exaustão da porta SNAT (PAT) do Azure.

Solução 1

Se você estiver executando em VMs do Azure, siga o guia de exaustão da porta SNAT.

Solução 2

Se você estiver executando no Serviço de Aplicativo do Azure, siga o guia de solução de problemas de erros de conexão e use o diagnóstico do Serviço de Aplicativo.

Solução 3

Se você estiver executando no Azure Functions, verifique se está seguindo a recomendação do Azure Functions de manter clientes singleton ou estáticos para todos os serviços envolvidos (incluindo o Azure Cosmos DB). Verifique os limites de serviço com base no tipo e tamanho da hospedagem do seu aplicativo de função.

Solução 4

Se você usar um proxy HTTP, verifique se ele pode suportar o número de conexões configuradas no SDK ConnectionPolicy. Caso contrário, você enfrentará problemas de conexão.

Criar várias instâncias de cliente

A criação de várias instâncias de cliente pode levar a problemas de contenção de conexão e tempo limite. Os Diagnósticos contêm duas propriedades relevantes:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated rastreia o número de vezes que um CosmosClient foi criado dentro do mesmo AppDomain e NumberOfActiveClients rastreia os clientes ativos (não descartados). A expectativa é que, se o padrão singleton for seguido, X corresponda ao número de contas com as quais o aplicativo trabalha e que X seja igual a Y.

Se X for maior que , significa que o aplicativo está criando e descartando instâncias de Ycliente. Isso pode levar à contenção de conexão e/ou contenção de CPU.

Solução

Siga as dicas de desempenho e use uma única instância do CosmosClient por conta em todo o processo. Evite criar e descartar clientes.

Chave de partição instantânea

O Azure Cosmos DB distribui o débito aprovisionado global uniformemente entre as partições físicas. Quando existe uma partição instantânea, uma ou mais chaves de partições lógicas numa partição física estão a consumir todas as Unidades de Pedido de partição física por segundo (RU/s). Ao mesmo tempo, serão utilizadas as RU/s noutras partições físicas. Como sintoma, o total de RU/s consumido será menor do que o RU/s provisionado geral no banco de dados ou contêiner, mas você ainda verá limitação (429s) nas solicitações em relação à chave de partição lógica ativa. Use a métrica Consumo de RU normalizado para ver se a carga de trabalho está encontrando uma partição quente.

Solução

Escolha uma boa chave de partição que distribua uniformemente o volume de solicitação e o armazenamento. Saiba como alterar a sua chave de partição.

Elevado grau de simultaneidade

O aplicativo está fazendo um alto nível de simultaneidade, o que pode levar à contenção no canal.

Solução

A aplicação cliente que utiliza o SDK deve ser aumentada vertical ou horizontalmente.

Grandes pedidos ou respostas

Grandes solicitações ou respostas podem levar ao bloqueio do head-of-line no canal e exacerbar a discórdia, mesmo com um grau relativamente baixo de simultaneidade.

Solução

A aplicação cliente que utiliza o SDK deve ser aumentada vertical ou horizontalmente.

A taxa de falha está dentro do SLA do Azure Cosmos DB

O aplicativo deve ser capaz de lidar com falhas transitórias e tentar novamente quando necessário. Quaisquer exceções 408 não são repetidas porque em criar caminhos é impossível saber se o serviço criou o item ou não. Enviar o mesmo item novamente para criar causará uma exceção de conflito. A lógica de negócios de aplicativos de usuário pode ter lógica personalizada para lidar com conflitos, o que quebraria a ambiguidade de um item existente versus conflito de uma nova tentativa de criação.

A taxa de falha viola o SLA do Azure Cosmos DB

Entre em contato com o Suporte do Azure.

Próximos passos