API da Web do Azure - aguardando conexão sql a cada 4 minutos e 30 minutos

Dentro de uma solicitação em um ApiController, estou acompanhando a duração da espera pela abertura da conexão Sql.

await t.TrackDependencyAsync(async() => { await sqlConnection.OpenAsync(); return true; }, "WaitingSqlConnection");


Se minha solicitação não for solicitada por pelo menos 5 minutos, qualquer nova chamada exibirá a duração deOpenAsync ser enorme (c. 3s) em vez de imediato.

Eu gostaria de entender o motivo de erradicar essa lentidão louca.

ATUALIZAR

Eu criei um terminal apenas para abrir oSqlConnection. Se eu esperar mais de 5 minutos, chame issoOpenConnection endpoint, em seguida, chame qualquer outra solicitação, oOpenConnection incorrerá no custo de espera mencionado acima, mas a solicitação não.

Por isso, agendei um trabalho no Azure para ser executado a cada minuto e chame oOpenConnection ponto final. No entanto, quando faço solicitações do meu cliente http, incorro no tempo de espera. Como se tivesse aberto oSqlConnection estava de alguma forma ligada ao cliente http http ...

Além disso, essas janelas de 5 minutos são típicas do DNS TTL ... No entanto, os 3s para uma pesquisa de DNS no terminal de banco de dados são muito longos. Não pode ser isso.

ATUALIZAÇÃO 2

O tempo observado no nível do cliente de ativação parece ser o resultado da espera pela conexão e de algumas outras latências (pesquisa de DNS?).

Aqui está uma tabela resumindo o que observo:

ATUALIZAÇÃO 3

A diferença entre as linhas 3 e 4 da minha tabela é o tempo gasto no TCP / IP Connect e no HTTPS Handshake, de acordo com o Fiddler. Não vamos focar nisso nesse post, mas apenas no tempo gasto aguardando oSqlConnection abrir.

ATUALIZAÇÃO 4

Na verdade, acho que os dois tempos de espera têm o mesmo motivo.
O servidor precisa "manter viva" sua conexão com o banco de dados e o cliente precisa "manter viva" sua conexão com o servidor.

ATUALIZAÇÃO 5

Eu tinha um trabalho sendo executado a cada 4 minutos para abrir oSqlConnection mas de vez em quando incorria no custo de espera. Então, acho que o tempo de inatividade é de 4 minutos e não 5 (por isso, atualizei o título deste post).
Atualizei meu trabalho agendado para ser executado a cada minuto. então percebi que ainda estava incorrendo no custo de espera, mas regularmente a cada 30 minutos (atualizei o título deste post).
Essas duas vezes se correlacionam estranhamente com as deTempo limite inativo do balanceador de carga do Azure.

questionAnswers(0)

yourAnswerToTheQuestion