30 seconds delays in server response

Question

After examining the Wireshark flow graph. The clients connects to the the server then after the PSH, ACK it takes the server 30 seconds to respond. This happens 6 times in the total conversation, making data transfer take forever. Win7 PC connecting to a VM CentOS 5.7. VMWare are tools installed. Does any one have any ideas what might cause this 30 second delay in server response? Any help appreciated.

4   0.001504000 192.168.1.114   192.168.10.89   TCP 51416 > netview-aix-6 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=344
5   0.001825000 192.168.10.89   192.168.1.114   TCP netview-aix-6 > 51416 [ACK] Seq=1 Ack=345 Win=6912 Len=0
6   30.017798000 192.168.10.89  192.168.1.114   TCP netview-aix-6 > 51416 [PSH, ACK] Seq=1 Ack=345 Win=6912 Len=722
7   30.019302000 192.168.1.114  192.168.10.89   TCP 51416 > netview-aix-6 [PSH, ACK] Seq=345 Ack=723 Win=64814 Len=242

Answer 1

As you are not mentioning what kind of protocol is used, it's hard to tell from just the packet capture.

What you do know is that it is a delay in the server (assuming the trace was made on the server side to exclude any intermediate devices). So the 30 sec delay is something on the server side. If it is (close to) 30 sec all the time, then it does not sound like processing time, but more like a timeout being hit.

You would need to know more about the application on the server to determine the exact cause.

Answer 2

Lets take a look:

In packet 4, 334 bytes are sent from IP 192.168.1.114 to 192.168.10.89 (the latter of which I guess is your server), and the server acks it right away (well, about 0.3ms later) in packet 5 with a payload of 0 bytes. So far so good - all data sent and acknowledged for. Both systems are happy and have nothing else to say apparently.

In packet 6, the server sends 722 bytes to the client, which are acknowledged in packet 7 with a delay of about 2ms. Also not too bad. Since there had been no client data that the server had to react to you can ignore the delta time here. Servers only need to send packets fast if they have been asked for data, which is not the case here.

I think the 30s delta between packet 5 and 6 tells the story - if you ever encounter a number that "nicely" aligned to a timeout value a human programmer would select (typically numbers close to 10, 15, 20, 30, 45, 60, 90, 120 seconds) it is an application issue. Maybe both client and servers had nothing to say to each other, so they waited - very often you'll see packets like yours when two nodes are doing TCP keep alives to keep the session from timing out.

So unless you know that the application is slow you can disregard the pattern you found. But if the application is slow you'll need to ask the application guys what they're doing in the 30 seconds time window, and why they do not process data faster.