Tempo de download lento no servidor TomEE na instância do AWS EC2 Windows Server 2008

Question

Eu tenho uma máquina Tomee 1.5.1 em execução na instância AWS m1.medium com Windows Server 2008 .

Eu coloquei no servidor um arquivo .jpg estático de 2.5 MB e ele me leva em torno de 25 seconds para baixá-lo na minha máquina com o Chrome.

Ao observar o tráfego no Wireshark, vejo que o receptor Window Size é constante em 64 KBbytes , quando a janela do receptor é 256 e o fator de escala é 256 (deslocamento à esquerda de 8).

Atrocatípicaé:

Fatoreseliminados:

1. Oservidorestásobrecarregado-nãoé.

2. Oservidortembaixalarguradebanda-nãoé,pelomenosquandoaconexãoéinicializadaapartirdoservidor.Aoexecutaroooklaspeedtestnamáquinadoservidorparaalgunsprovedoresdebenchmarkemtornodeminhalocalização,aparece/descendecercade60Mbps.

3.Oreceptorestálento/malconfigurado-nãoé-omesmoarquivoébaixadodealgumservidordecompartilhamentodearquivosem2segundos.Otamanhodajanelasaltaàmedidaqueotráfego/congestionamentoaumentacomodeveriaeémuitomaior.

Editar1

Desativarheurísticanocliendnãoajudou

Editar2

Aperguntaadicionaléporqueoremetentepareceenviarosdadosnumasériede1460*6+240=9000bytes,enãotermaisdoqueumasérie"excelente", o que significa que ele envia o novo grupo assim que ele o bando um-antes-anterior

Editar3:

AcontecequeoconectorhttptemumaconfiguraçãosocketBuffer-"O tamanho (em bytes) do buffer a ser fornecido para o buffer de saída do soquete. -1 pode ser especificado para desativar o uso de um buffer. Por padrão , um buffer de 9000 bytes será usado ". - Estes são exatamente 9000 bytes que vemos nos lotes de saída.

Provavelmente, o driver tcp armazena os pacotes de saída no buffer para retransmiti-los em caso de necessidade, até obter a confirmação e, por algum motivo, os clientes estão recebendo de volta em lotes, portanto, o lote do tráfego de saída .

Se mudarmos para 4MB, o lote aumentará para 64KB ...

Se o tráfego não estiver criptografado por SSL. Se o SSL estiver ativado, o lote é de 16kb.

É necessário verificar o seguinte:

1. Qual é o tamanho ideal do buffer em conexões com ping baixo? Eu acho que 64k pode ser ok.
2. Como o buffer de saída SSL é configurado
3. Experimente a versão mais recente do tomee - há atualizações no conector http
4. Confira o conector NIO
5. Por que os ACKs estão chegando em lotes?

Editar 4:

1. O tamanho do buffer de 64k faz uma pequena diferença. Eu me acomodei com 128k para estar no lado seguro.

2. Se usarmos o Tomee 7 no Windows Server 2016, o SSL funcionará tão rápido quanto o tráfego HTTP normal. Eu não sei por enquanto quando entre tomcat5-win2008 e tomcat7-win2016 a mudança ocorreu.

Answer 1

Com o Windows parece haver duas coisas discutidas, primeiro verifique sua configuração atual:

netsh int tcp show global

Geralmente, é sugerido que o desligamento automático seja desativado, mas isso também desativará o dimensionamento. Portanto, usar restricted parece ser realmente melhor para dimensionamento. Desligar a sintonização automática também desativará a escala, por isso não faça isso.

Além disso, algumas pessoas relatam que a desativação da heurística de dimensionamento de janelas no cliente faz com que o recurso seja solicitado de forma mais consistente. O 256 * 255 parece ser uma combinação típica quando o Windows subestima a qualidade do link.

Confira também este artigo sobre otimizações de PSH no lado do cliente e do servidor (especialmente para o Windows). Parece-me a partir de seus diagramas de seqüência que o cliente espera muito tempo para ack pacotes (esperando pelo PSH do servidor). link