This capture was taken at the server. It is transferring a ~12MB file using HTTP. The RTT is 220ms I concluded from the capture that the server transmitting the file, is holding up the transfer by only transmitting in 9000 Byte chunks, then waiting for an ACK. The max bytes in flight is 18,000 Bytes, even though the client is advertising an RWIN of 65535. Does anyone have any other thoughts on this analysis? Here's a link to an anonymized version of the capture: https://www.cloudshark.org/captures/94b162026653 asked 03 Nov '16, 14:56  crrimson |
One Answer:
Ok. If we are talking about Tomcat, then this page can help you, too. http://javaagile.blogspot.de/search?q=tomcat I think you should try tune the TX-Buffers. Because when the server has send a segment with the PUSH Bit = 1 he waits for the ACK (a pause of about 200ms). More I can´t see, because the packets are truncated. answered 04 Nov '16, 13:54  Christian_R edited 04 Nov '16, 14:13 My initial conclusion was that it was this value: socketBuffer. Still waiting on the server team to change & re-test further. Described here: https://tomcat.apache.org/tomcat-6.0-doc/config/http.html "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." I watched the video on Packetbomb, and it seems very similar, but we aren't even sending 64K before PSH, we are sending 9K.. (04 Nov '16, 14:30) crrimson Yes, that seems to be the limiting value. (05 Nov '16, 01:15) Christian_R |
About what webserver we are talking? Maybe this helps you a little bit. As I have seen some time gaps at cloudshark. But don´t have anymore time to analyze deeper at the moment. http://packetbomb.com/solving-tomcat-throughput-issues-on-windows/
This happens to be a Tomcat server haha. I love packetbomb, somewhat surprised I didn't find this link before! Thanks.
I also want to note that on a test server I was able to modify the socketBuffer variable in Tomcat config and noticed some performance differences... I'll watch that video, and reply back.