I have a
Tomee 1.5.1 machine running on
AWS m1.medium instance with
Windows Server 2008.
I put on the server a static
.jpg file of
2.5 MB, and it takes me around
25 seconds to download it on my machine with Chrome.
When observing the traffic in Wireshark, I see that receiver the
Window Size is constant on
64 KBbytes, when the receiver window is 256 and the scaling factor is 256 (shift left of 8).
The typical exchange is:
The server is overloaded - it is not.
The server has low bandwidth - it is not, at least when the connection is initialized from the server. When running ookla speedtest on the server machine to some benchmark providers around my location is shows up/downlink of around 60 Mbps.
3.The receiver is slow/misconfigured - it is not - the same file gets downloaded from some file sharing server in 2 sec. The window size jumps as traffic/congestion increases as it should and is much larger.
Disabling heuristics on the cliend didn't help
Additional question is why the sender seems to send the data is series of 1460*6+240=9000 bytes, and to have not more then one "outstanding" series, that means he sends the new bunch once he got ack to the one-before-previous bunch
It turns out, the http connector has a setting
socketBuffer - "The size (in bytes) of the buffer to be provided for socket output buffering. -1 can be specified to disable the use of a buffer. By default, a buffers of 9000 bytes will be used." - These are exactly 9000 bytes we see of the outgoing batches.
Likely, the tcp driver stores the outgoing packets in the buffer to retransmit them in the case of need, until it gets the ack, and for some reason the client acks are getting back in batches, hence the batching of the outgoing traffic.
If we change it to 4MB, the batching increases to 64KB...
If the traffic is not SSL encrypted. If the SSL is on, the batching is 16kb.
Need to check out the following:
- What is the optimal out buffer size on connections with low ping? I think about 64k can be ok.
- How is SSL output buffer configured
- Try newer version of tomee - there are updates to the http connector
- Check out the NIO connector
- Why the ACKs are arriving in batches?
The buffer size of 64k makes a little difference. I settled with 128k to be on the safe side.
If we use Tomee 7 on Windows Server 2016, the SSL works as fast as regular http traffic. I don't know for now when between tomcat5-win2008 and tomcat7-win2016 the change occurred.