lentidão da rede [fechada]

Question

Estou enfrentando um problema no meu projeto. Oferecemos suporte a um aplicativo hospedado em um servidor unix.

Os parceiros tentam acessar o mesmo em várias regiões. Agora, alguns usuários em uma região dizem que "R" está reclamando sobre a lentidão e temos motivos para acreditar que isso pode ocorrer devido a um problema de rede que está no seu final.

Quais são alguns comandos que posso executar em seu sistema em seu terminal, através dos quais posso provar a eles que é um problema de rede no final?

Também alguns comandos que podem provar a eles que outros aplicativos da web nos últimos minutos também levaram muito tempo em seus sistemas?

Sou muito novo no UNIX. Obrigado antecipadamente.

    

Answer 1

Limitações inerentes

O problema pode ser variável (por exemplo, link congestionado para o ISP ou congestionamento no ISP). Também poderia ser horrível ("firewall" ou mesmo "anti-vírus" fazendo inspeção profunda de pacotes); as ferramentas abaixo podem não mostrar nenhum problema. Eles valem a pena, mas há um limite para o quanto você pode conseguir digitando comandos em um terminal.

2 testes que você deve saber

1. Use ping para medir a latência de ida e volta aos servidores por meio de ICMP / IP. Você também pode traceroute ou tracepath para o seu servidor e verificar quanta latência de ida e volta há nos primeiros saltos. Você está principalmente tentando verificar os sintomas do bufferbloat, então esteja ciente de que isso só acontece quando o link é totalmente usado! (medida "latência sob carga").

2. Você pode verificar a largura de banda de download da Web disponível (fluxo único) usando apenas wget ou curl --remote-name para baixar um arquivo. Se você é sem inspiração, sugiro baixar um Linux :-). Encontre o link de download e use "copiar local do link" no menu do botão direito do mouse. Você provavelmente não precisa deixar o download finalizado porque ele mostrará a taxa de download atual - use Control + C para cancelá-lo. Você pode testar um espelho na mesma região do seu servidor (isso é potencialmente significativo). Eu acho que se você está considerando o terminal, é bom saber que wget existe. Pessoalmente, prefiro usar o link .

Isso é basicamente , a partir das informações que você deu. Há uma ressalva com um dos resultados de ping , que eu destaquei abaixo.

ping é excelente para testes iniciais. traceroute é uma ferramenta especializada. Sugiro apenas traceroute como uma maneira de ilustrar o bufferbloat, se é isso que o ping parece mostrar ... na verdade, é melhor usar ping nos roteadores que você vê em traceroute .

Baixas taxas de download como causa direta podem ser facilmente superestimadas. Webapps não precisam para servir muitos dados para responder às solicitações do usuário, a menos que haja imagens não armazenadas em cache. Por exemplo. O unix.stackexchange.com tem 75K e leva 0,2s para download a 4Mb / s. Mas é fácil executar um teste e fornece um pequeno ponto de dados para se encaixar no quebra-cabeça.

Quanto a perda de pacotes (ping) é demais?

Qualquer taxa perceptível de perda de pacotes pode limitar a taxa de download, e particularmente em relação ao trans-continental distâncias .

Infelizmente, o efeito da perda em transações curtas é um pouco mais complicado do que isso . Parece que uma única perda provavelmente não causará mais de 100% de aumento para transferências em torno de ~ 20Kb. A menos que o primeiro pacote do servidor (ou cliente) seja descartado, caso em que não será recuperado até um "tempo limite de recebimento" completo - 3 segundos .

Há um problema / advertência ao medir a perda, pois ela pode ser afetada pelo tamanho do pacote. Ao medir a perda com ping , você deve notar que usa pacotes pequenos por padrão . Isso é semelhante aos primeiros pacotes do cliente e do servidor (SYN / SYN-ACK, respectivamente). Juntando tudo isso, se você perceber 5% de perda ao executar ping $SERVER sem opções, não esperaria uma experiência perfeita ao usar esse aplicativo da web. (Ou seja, de 20 ações do usuário, espere que 1 delas demore 3 segundos antes que algo aconteça. Não será mitigado por conexões persistentes dadas configuraçõescomuns do servidor web )

Você pode verificar estatísticas para pacotes de tamanho completo, por exemplo ping -s 1400 no unix. Em princípio, pode haver ainda mais fatores ("priorização" no roteador aka QoS) e o que você deseja especificamente são os detalhes de retransmissão TCP do aplicativo específico, reunidos a partir do kernel ou de um rastreio de pacotes .

Observe que, a partir de um endpoint, é muito difícil distinguir se um link está congestionado, v.s. se o link é fisicamente não confiável. A perda de pacotes é como os roteadores informam ao TCP para diminuir a velocidade; links mais congestionados terão mais perda de pacotes. Acho que o melhor que você poderia esperar é identificar ("provar") um link com alta perda de pacotes e pedir a alguém com acesso para investigação ou monitoramento.