Um rastreamento de rede (por exemplo, Wireshark) mostrará se o atraso está aguardando uma resposta. Também indicaria outros "desvios", como a sugestão sobre o DNS. Parece que você já fez isso, mas não disse.
Configurações: esta é uma máquina com quatro CPUs, muito strong, não carregada (nem CPU nem rede), o cliente é um servidor Windows Server 2008 de 64 bits, o servidor é uma caixa linux.
Eu tenho quatro threads que estão emitindo solicitações HTTP iniciando ao mesmo tempo. As conexões são iniciadas para os IPs X, X, Y, Z (duas conexões para X, uma para Y e Z). Todos os alvos estão na LAN local.
Estou vendo que as conexões para X, Y e Z são formadas (SYN-SYN / ACK) e a segunda conexão para X é com um atraso de 100 ms. Ou seja, a máquina não está enviando o segundo SYN para X por 100 ms.
Isso pode estar relacionado ao Motor TCP Offload ? O que mais poderia estar causando esse atraso?
Editar - Outro suspeito é o código do cliente - está escrito em Java e usa o HttpURLConnection.
Um rastreamento de rede (por exemplo, Wireshark) mostrará se o atraso está aguardando uma resposta. Também indicaria outros "desvios", como a sugestão sobre o DNS. Parece que você já fez isso, mas não disse.
Uma possibilidade diferente: o limite do Windows XP SP2 em conexões abertas pela metade, cujo padrão é 10. Não sei como você vê quantas conexões estão nesse estado, mas acredito que se esse limitador de taxa entrar em ação ele aparecerá nos registros de erros.
Será necessário fazer uma pesquisa de DNS para cada solicitação? Isso limita a taxa?
A conexão inicial passa bem, mas é sua segunda conexão que está sendo enfileirada. Eu revisaria a implementação do cliente no software, não sei se os JDKs mais recentes fizeram mais alterações, mas costumava ser que, mesmo que você fizesse HttpUrlConnections individuais, o Manipulador de Protocolos subjacente ainda usaria novamente a conexão de soquete.
Você deve fazer o check-in no StackOverflow e ver se alguns deles já lidaram com esse problema antes.
OK, há muitos lugares possíveis que podem estar dando errado. Você mencionou o mecanismo de descarregamento do TCP, e esse é um suspeito razoável (especialmente se você tiver NICs da Broadcom lá), então vamos descartá-lo e desativá-lo (consulte sua documentação para isso).
Depois disso, você quer começar a reduzir outros possíveis candidatos, então olhe para switches, cabos de rede e assim por diante. Se puder, conecte a origem ao destino por meio de um cruzamento e veja se consegue reproduzi-lo lá.
Também vale a pena tentar o velho e querido ping - pelo que parece, você deve ser capaz de reproduzir o comportamento aberrante com 4 pings simultâneos.
Mas o que se resume é que não há sentido em suspeitar de qualquer coisa neste estágio inicial, pois há muitos lugares em que poderia estar errado (incluindo seu aplicativo).
Você verificou suas configurações de firewall? Pode haver algo nas configurações do firewall que limitem as conexões.
Você tem alguma configuração especial de sysctl para o servidor? Há muitos pequenos ajustes que um pode fazer pela rede em sysctl.
Você verificou em servidores / clientes diferentes? Isso serve para ajudar a isolar a causa do problema - seja o servidor específico, o cliente ou ambos.