O TCP relata latência de 20 ms entre o Web Farm e o DB

1

Temos um farm da Web do IIS em uma DMZ conectando a um MSSQL DB (Windows Cluster). Depois de solucionar alguns problemas de desempenho, nos deparamos com um comportamento estranho da rede.

Queríamos testar a latência de rede em geral entre os dois servidores, mas o ping é bloqueado pelo firewall, por isso tentamos usar uma versão do tcping para testar a latência especificamente para o servidor db na porta 1433. O TCP relata uma latência de ~ 20 ms. O mesmo TCP da minha estação de trabalho para o servidor de banco de dados é ~ 2ms. Meu primeiro pensamento foi que este é o firewall entre o servidor da Web e do banco de dados, portanto, para confirmar minha suspeita, executei outro TCP de outro servidor de aplicativo dentro da rede e também relatei a latência de 20 ms. Então comecei a executar o mesmo TCP de alguns outros servidores. Alguns relatam latência de 2ms e alguns relatam quase 20ms.

As operações de rede estão me dizendo que as variações são mais prováveis devido à configuração do sistema operacional, pois os servidores que testei estão nos mesmos segmentos de rede (com exceção dos servidores da web).

Nos servidores em que o TCP relata latência de 2 ms, vemos uma melhora significativa no desempenho.

Existe algum tipo de configuração de rede no Windows que possa estar causando esse comportamento? Alguém tem outras sugestões (outras ferramentas de monitoramento, outras possíveis causas, etc.)?

Atualizar Apenas tentei TCP para o ip local, não 127.0.0.1 mas as máquinas ip real e também vejo latência (algo como 15-18ms). Eu fui em torno de vários servidores e observei um comportamento similar. Isso não parece normal, alguma idéia? Nem todos os servidores exibem esse comportamento.

    
por Dan 24.04.2013 / 13:54

4 respostas

2

Bull, as operações de rede são incompetentes.

2ms não é pequeno, mas está bem.

20ms é escandaloso. Isso é um link WAN ou uma linha sobrecarregada ou algo assim.

A tecnologia NO LAN em um prédio lhe dará 20ms, mesmo que você passe por meia dúzia de roteadores.

Não tenho conhecimento de qualquer configuração incorreta.

O bloqueio do ICMP pode causar efeitos colaterais, como pacotes TCP descartados. Quem desligou isso deve aprender sobre TCP / IP antes de configurar firewalls. Pelos padrões TCP, a rede é quebrada devido à falta do ICMP (que é usado, por exemplo, para localizar o tamanho máximo do segmento que pode ser transportado com segurança).

    
por 24.04.2013 / 13:59
1

Configuração do SO? Eu vi esse tipo de latência quando a porta do switch e a NIC não estavam concordando em velocidade e duplex. Isso é definido dentro do sistema operacional no lado da NIC. No entanto, se isso estiver ocorrendo, eles devem estar recebendo erros nas portas do switch em questão.

Onde a configuração do SO entra em ação em relação ao desempenho é com o SMB, já que isso difere entre as versões do SO e as configurações do sistema operacional pode fazer com que o Windows Server 2003 e o Windows Server 2008 não funcionem bem juntos. No entanto, isso não está relacionado à latência da rede e é um protocolo completamente diferente do que você usa para se conectar ao SQL Server ou, provavelmente, ao que é usado pelo TCP.

    
por 24.04.2013 / 14:08
1

É no hardware que o hardware em si é insuficiente ou mal configurado. é uma ou duas camadas, ou regras de firewall dão boa sorte a elas.

Quando você está copiando o SQL de um servidor IIS, capture o tráfego usando o wireshark instalado no SQL. Capture tudo e depois dilua com o filtro de exibição. ou você pode fazer um filtro de captura como: a porta TCP 1433 e clicar com o botão direito em um pacote e seguir o fluxo TCP ...

Faça com que seus administradores do FW vejam isto: link

Há mais do que apenas 1433 para abrir e parece que eles não são muito bons nisso e, nesse caso, o conjunto de regras deles é suspeito, a entrada icmp da DMZ deve ser bloqueada. Não deve ser usado. dentro de um núcleo onde sua estação de trabalho e SQL estão bem. Eu estou supondo que sua rede é logicamente duas camadas, um público onde seu IIS se senta e núcleo onde o SQL é.

Por segmento, eles significam sub-rede ou vlan? Se é VLAN, então há regras para lá .... você pode ter o "segmento" aberto para TCP 1433, e não UDP ou você tem um vlan um host está faltando ou não lá que deveria ser, em vez disso, é em outro.

você configurou o sistema operacional para não fazer o serviço de navegador de computador, o WINS, coisas assim, por isso não está tentando identificar seu SQL por netbios? Isso pode atrasar as coisas.

Eu abriria uma captura wireshark na sua caixa SQL e veria o que você vê. Você pode desativar os pacotes autoscroll em captura ao vivo para que eles não saiam gritando. Deixe-o capturar fazer algumas transações, em seguida, pare com isso e use o filtro de exibição de modo a detalhar, faça como tpc.port eq 1433 eu acho. o filtro de captura seria: a porta 1433 e que obtém todos os protocolos destinados apenas ae a partir de 1433 na sub-rede da qual essa máquina é membro.

Você provavelmente verá muitos Retransmits, Acks duplicados e coisas dessa natureza. Olhe para o ARP, veja se tudo está indo bem, se você vê o tráfego do netbios fazendo o que você tem que desligá-lo no sistema operacional. Como no IIS nic você tem o windows client desmarcado ou o compartilhamento de arquivos na pilha de rede, eu esqueci exatamente do topo da cabeça. Você deseja apenas TCP e UDP, a partir do SQL e do IIS. sem NetBT, NetBios ou qualquer outra coisa. TODOS DNS, sem WINS, etc ... boa sorte com sua equipe de rede.

    
por 24.04.2014 / 19:24
0

Eu tentaria desabilitar o offload de chaminés TCP link

    
por 05.05.2013 / 03:48