IIS: Como saber se um tempo lento é devido a uma conexão de rede lenta

Question

De acordo com o link , "quando uma resposta grande ou grandes respostas são enviadas a um cliente por meio de uma conexão de rede lenta, o valor do campo time-taken pode ser mais do que o esperado ".

Eu tenho uma situação em que um cliente vai dizer: "Eu enviei um pedido para o seu servidor web às 10:03:24 e demorou 20 segundos, por quê?". Também posso ver isso nos logs do IIS, mas o módulo ASP.NET do servidor registrou como tendo 100ms e os contadores de CPU e de disco estavam baixos.

Eu suspeito que seja devido a uma conexão de rede lenta. Como posso provar isso?

Atualização:

1) Estas são solicitações de serviço web SOAP, portanto, não há gráficos incorporados, apenas um HTTP POST com uma única página XML de resultados.

2) Também reproduzi isso limitando a velocidade da rede no lado do cliente e os sintomas são exatamente os mesmos.

3) O problema é intermitente, o que significa que o mesmo pedido é normalmente rápido para o cliente, mas ocasionalmente lento. Eu não posso reproduzir isso sozinho a não ser por estrangular a rede. O log do ASP.NET do servidor mostra-o sempre rápido, mas o log do IIS mostra lentidão quando o cliente diz que está lento.

4) Eu só tenho acesso ao servidor, e preciso fornecer o máximo de informações possível para o cliente, para que eles aceitem que o problema não estava no servidor e sabem que ferramentas de registro / execução devem ser executadas no cliente para localizar raiz causa.

    

Answer 1

I have a situation where a client will say, "I sent a request to your web server at 10:03:24 and it took 20 seconds, why?". I can see this in the IIS logs as well, but the server's ASP.NET module logged it as taking 100ms, and CPU and Disk counters were low.

I suspect that it's due to a slow network connection. How can I prove this?

Ele começa com a procura de pacotes entre o navegador do seu cliente e todos as fontes de imagens / scripts / html para a página da Web mencionada anteriormente. Se você encontrar pacotes consistentes, você tem certeza de que há algo na rede que precisa ser corrigido ... mesmo que seja apenas um link que está sobrecarregado. Os pacotes não são a única razão para uma rede lenta, mas é a fonte mais comum na minha experiência. Outras fontes podem ser um proxy ou mecanismo de cache mal configurado. Infelizmente, não posso listar todos os possíveis culpados de rede aqui.

No entanto, as pessoas geralmente culpam a rede, quando, na verdade, os problemas de velocidade estão bem dentro de seu próprio controle. Possíveis explicações:

• Suponha que o HTML dessa página tenha sido gravado incorretamente e carregue os scripts necessários na ordem errada, de modo que a página inteira seja processada lentamente, mesmo que quase todos os recursos estejam no local.
• A página está aguardando um recurso que simplesmente não existe e expira durante a espera.
• Um script está em um loop lento que bloqueia por um tempo
• Um mecanismo de cache demora muito para entregar uma imagem
• Seu CGI está procurando algo em um banco de dados e a pesquisa em si é lenta
• Você está usando o google analytics , o que atrasa as coisas devido à forma como a página é escrita

Eu poderia continuar, mas o ponto é que você tem que descobrir o motivo exato pelo qual a página está lenta. Uma rede falha é possível; Também é possível que outros fatores estejam contribuindo para o desempenho lento.

Para diagnosticar mais:

• Se a página for bem carregada no Firefox, a guia Rede no Firebug é seu amigo (Hit F12 , em seguida, vá para a guia Rede e recarregue a página). O Firebug fornece um belo diagrama em cascata sobre como a página é carregada e onde os atrasos são
• SeapáginaforbemcarregadanoChrome,vocêpoderáfazeralgosemelhante(HitCtrl+DeslocarI,clicarnaguiaderedeerecarregueapágina).
• Se a página só é suportada no IE (btw, vergonha em seus desenvolvedores de HTML), sua melhor aposta é começar a carregar cada um desses elementos de página ASP individualmente com curl até encontrar algo que pareça lento demais e, em seguida, descubra por que esse elemento em particular é lento.

BTW, os exemplos do Chrome e do Firefox usaram uma consulta CGI do Debian.org ; este é um bom exemplo de um atraso que vem de uma consulta CGI.

Quando tudo mais falhar, você poderá obter um .pcap de wireshark e executá-lo em tcptrace ; No entanto, enquanto tcptrace é muito bom em analisar os despejos de pacotes, não há garantias de que você possa isolar o problema com tcptrace sozinho. Consulte esta resposta para obter informações sobre o uso de tcptrace diagnostics.

    

Answer 2

O resultado do artigo kb 944884 é que o tempo real necessário para completar a resposta pode não ser refletido com precisão no log. É por isso que o artigo menciona o tempo da rede.

Se o sintoma for reproduzível, eu executaria uma captura de pacote no lado do servidor (e preferencialmente no lado do cliente também) para ver as horas reais em que a conexão foi confirmada pelo cliente.

    

Answer 3

O atraso de 20 segundos também pode ser causado pelo IIS ter que reiniciar o w3wp.exe, que entrará em suspensão quando não for usado.