O tipo de espera ASYNC_NETWORK_IO é algo com que se preocupar?

Ao examinar a lista de procedimentos armazenados que demoram muito tempo para serem executados, destaca-se que causa a maior espera. No entanto, a maior parte dessa espera (81%) é ASYNC_NETWORK_IO e eu sei o porquê: o procedimento armazenado transfere aproximadamente 400 MB de informações.

Na documentação, ele afirma que a causa do ASYNC_NETWORK_IO é que o cliente não pode acompanhar o fluxo de dados e isso provavelmente é verdade. Não tenho certeza de como manter o cliente atualizado, pois tudo o que faz é chamar o procedimento armazenado por meio de um ADO.NET e depois apenas processar o conjunto de dados.

Portanto, considerando essas informações, devo me preocupar com o tipo de espera ASYNC_NETWORK_IO para este procedimento? Isso realmente afeta o desempenho do servidor?

Informações adicionais:

Estou no service pack 2 do SQL Server 2005.
O aplicativo cliente está na mesma caixa do SQL Server (eu sei, eu sei ... mas não posso fazer nada sobre isso).

— AngryHacker
fonte

A melhor maneira de pensar sobre esse tipo de espera é que não há nada na sua consulta causando isso - está retornando dados ao cliente. Você também verá isso muitos de vocês vincularam tabelas no Access. Uma possibilidade, dependendo do aplicativo do cliente, é dividir os dados em partes menores ou apenas retornar menos dados. Se isso não for uma opção, você provavelmente será limitado no que pode fazer para reduzi-la.

— 23414 JNK

O aplicativo cliente está se conectando usando Memória Compartilhada ou TCP / IP? O aplicativo cliente e o SQL Server estão compartilhando o mesmo conjunto de núcleos de processador ou você está usando uma técnica de mascaramento de afinidade para separá-los?

— Jon Seigel

É o tipo de conexão padrão - nada de especial - por isso está usando a memória compartilhada. Ambos os aplicativos usam o mesmo conjunto de núcleos - não há afinidade.

— AngryHacker 23/01

O seu armazenamento é SAN ou local?

— Eric Higgins

@EricHiggins Apenas um conjunto local de discos rígidos RAID.

— AngryHacker

Como você disse, esse tipo de espera indica que o aplicativo não está acompanhando o SQL Server. Agora, o que realmente significa é que o SQL Server não pode enviar os dados pela rede tão rápido quanto gostaria.

Pode haver duas causas subjacentes:

O aplicativo foi escrito de maneira ineficiente e não processa as linhas com rapidez suficiente.
A rede está no limite máximo.

Se o aplicativo em si for muito lento, não haverá ou haverá impacto significativo no desempenho de outras consultas. Se, por outro lado, o canal for muito pequeno, outras consultas também não poderão enviar seus resultados e terão que esperar.

No último caso, no entanto, você teria todas as conexões aguardando ASYNC_NETWORK_IO. Você deve conseguir ver claramente esse impacto.

— Sebastian Meine
fonte

Para o ponto 1 do marcador. A recuperação de dados é feita via ADO.NET usando o código padrão: var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); Portanto, não tenho certeza do que exatamente pode ser lento.

— AngryHacker

Para o ponto de marcador 2. O aplicativo está na mesma caixa que SQL e a conexão é via método de Memória Compartilhada. Então, teoricamente, isso deve ser super rápido.

— AngryHacker 24/01