Esta é uma pergunta ingênua, eu acho. Eu freqüentemente preciso descobrir o que se o problema com um aplicativo da web ou é simplesmente um problema de rede - pacotes perdidos ou uma conexão lenta em qualquer ponto entre, digamos, seu chefe em uma conexão wifi ruim no aeroporto e no servidor web, ou o CDN e o servidor web ou o MySQL e o servidor web, ou memcached box ... Você entendeu. Além disso, como você sabe se é o servidor DNS?
Alguns de vocês estão perdendo o ponto. Não se trata de medir o desempenho de aplicativos da web. Esta é uma questão sobre como medir o desempenho da rede como um componente do desempenho de aplicativos da Web.
Configure o rastreio (talvez a possibilidade de uma querystring), mostrando a quantidade de tempo gasto em seções pesadas do código e a hora geral do servidor. Se o servidor criar a página em 0,2 segundos e demorar 10 segundos para carregar, você sabe que é a rede ou o navegador do usuário.
Você também pode usar a guia Rede no Firebug ou a exibição da linha do tempo no Fiddler para ver componentes individuais sendo desativados e quanto tempo levam.
Para ver se é o servidor DNS, você pode tentar ignorar o servidor DNS. Você pode fazer isso adicionando os nomes de host relevantes ao arquivo de hosts. Se, quando você tiver os endereços no arquivo de hosts, o servidor da Web parece estar respondendo muito mais rápido, então investigue o DNS ainda mais. Se o desempenho do site ainda for ruim, o problema é mais provável em outro lugar.
Mais avançado; Você também pode consultar o DNS diretamente com nslookup ou cavar. Certifique-se de consultar os servidores DNS autoritativos do domínio do site diretamente para ver seu tempo de resposta, em oposição ao tempo de resposta do servidor DNS local, que pode ter uma cópia em cache das entradas.
A melhor abordagem é basear seu desempenho na Web em sites com boa conectividade conhecida. Depois de ter estabelecido isso, você pode começar o processo bastante simples de estabelecer a causa da latência para o seu cliente em particular < - > problema de aplicativo da web do cliente em questão.
Minhas recomendações para a latência da linha de base seriam pingdom.com - US $ 10 / mês você obtém uma sólida análise de latência (eu tenho usado nos últimos seis meses - todas as edições que eles relataram tem sido real) de vários locais em a Internet, bem como monitoramento / notificação para problemas de site para baixo.
De particular importância para seus requisitos, é que eles estabelecem um registro de auditoria do desempenho de seus sites de vários locais nos Estados Unidos e também internacionalmente. Isso pode ser útil se você tiver um problema temporário e desejar fazer uma retrospectiva histórica.
Poder fornecer ao seu chefe (que é seu público-alvo na pergunta) um gráfico de latência média de doze locais diferentes fornece uma base sólida para identificar os problemas do lado do cliente (problemas de WiFi, DNS e laptop) em relação a um problema com o desempenho base do site e conexão com a Internet.
Problemas no servidor DNS, é claro, podem ser imediatamente solucionados fazendo com que o cliente coloque os mapeamentos IP de hostname e > apropriados no local / etc / hosts (ou, no caso do Windows, C: \ windows \ system32 \ drivers \ etc \ hosts) - Se o problema desaparecer quando você tiver o arquivo / etc / hosts apropriado configurado, é um indicador muito strong de que há um problema em sua cadeia de resolução (resolvedor local, primeiro servidor DNS na cadeia ou canônico)
Não é possível prejudicar a realização de testes de carga reais em vários locais também. Execute um teste de carga local e, em seguida, execute um de vários locais fora do seu centro de dados. Os testes locais devem fornecer uma boa base do que esperar em condições de LAN / local. Então você pode comparar isso com o que obtém externamente, e você pode ver que tipo de perda você está recebendo no final da rede. Obviamente, os testes externos terão tempos de carregamento mais altos, mas você precisa determinar o que é aceitável nesse domínio.
Além das outras recomendações, gosto de usar o Fiddler para ver exatamente quanto tempo as solicitações individuais estão realizando e quanto de largura de banda é usada. Ele é executado a partir do cliente, de modo que ele mostra quanto tempo cada solicitação leva desse perceptivo.
Além disso, experimente o YSlow, um ótimo complemento para o Firebug:
Parece-me que você precisa conhecer as conexões de rede para cada processo, a quantidade de tráfego para cada conexão de soquete, o tempo de resposta para cada soquete e uma maneira de visualizar os dados.
o appfirst.com trabalhou para nós.