Você já viu esse tipo de espera antes, não é? Bem, certamente é um tipo de espera que causou muita confusão. O foco imediato geralmente é dado à palavra “NETWORK”, mas na maioria das vezes não tem nada a ver com a rede!
O tipo de espera ASYNC_NETWORK_IO normalmente produzirá dois tipos de sintomas, sendo o primeiro a carga de trabalho da sessão esperando que o aplicativo cliente correspondente reconheça/processe um determinado conjunto de dados e informe ao SQL Server que está pronto para processar/reconhecer mais dados. O segundo sintoma é que pode haver um problema de desempenho na rede entre o aplicativo e a instância do banco de dados. Nos bastidores, o SQL Server mantém os dados em um buffer de saída até que uma confirmação seja recebida do cliente determinando se o consumo de dados é completo. ASYNC_NETWORK_IO é um sinal revelador de que o aplicativo não tem eficiência na leitura dos dados que requer de seu banco de dados de back-end. A rede subjacente também pode ter problemas que podem produzir esperas mais longas enquanto os dados são processados ​​e os sinais estão sendo enviados de volta do cliente para o servidor.



As possíveis causas para essa espera incluem:

• O código do aplicativo não está recuperando os dados corretamente
• Grandes conjuntos de dados solicitados pelo cliente
• Excesso de filtragem de dados que ocorrem no cliente ou no aplicativo
• Dispositivos de rede mal configurados, como placas, switches, etc.

Em um nível alto, um DBA pode querer verificar estas coisas:

• Revise o código do aplicativo e verifique se o aplicativo está lendo os dados de forma correta/eficiente. Por exemplo, seu aplicativo está recuperando um grande número de linhas apenas para processar uma linha por vez?
• Filtragem de dados desnecessária no lado do cliente/aplicativo? Limite as linhas.

Se os itens acima forem verificados, mas os problemas com ASYNC_NETWORK_IO permanecerem, isso pode ser devido à rede. Aqui estão algumas coisas que você pode analisar:

• Inspecione o link de comunicação de rede entre o aplicativo e a instância do banco de dados de back-end e verifique a largura de banda.
• Use sys.dm_io_virtual_file_stats para testar a latência geral da rede devido à carga ou à distância
• Examine a configuração da NIC no servidor de banco de dados para garantir que não haja falhas e/ou configurações ausentes.

O ASYNC_NETWORK_IO WAIT TYPE pode realmente ser um problema relacionado à rede, mas geralmente pode ser devido a um aplicativo cliente que não está processando seus dados com eficiência. Se o último for realmente o caso, então esta é uma oportunidade para DBAS e Desenvolvedores trabalharem juntos para entender o que o aplicativo realmente precisa no melhor interesse do desempenho do banco de dados back-end. Garantir que a maior parte da filtragem de dados seja feita no SQL Server é uma prática recomendada que pode ser alcançada por meio de exibições ou condições mais específicas de onde na sintaxe da transação.

Embora existam muitas maneiras de monitorar e medir a espera ASYNC_NETWORK_IO por meio do uso de DMVs catalogados e eventos estendidos no SQL Server, incentivamos nossa comunidade de DBAs do SQL Server a analisar o Spotlight Cloud da Quest, que fornece eficiência na determinação da causa raiz do tipo de espera consumo ao longo de um período histórico.