I have a web server who's perfmon stats report a TCP retransmittal rate of about 10%.

I also have a client who makes heavy use of this server reporting poor performance.

The performance problems started when we moved the server to a new hosting facility.

Does the high retransmittal rate strongly indicate a congestion issue somewhere between the server and the client?

I've done trace routes between the server and the client's public IP and the RTT times are consistently good. Does this evidence weaken the case for congestion?

  • What about QoS policing/queuing, is this technology involved? – eric Dec 2 '14 at 15:02
  • I do not know if there is QOS in the path. I do know that the devices that I control are not implementing it. – Aheho Dec 2 '14 at 17:11
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 11 '17 at 0:16
  • I'll accept the best answer. Ultimately the issue was resolved when the data center sent the traffic over a different path – Aheho Aug 11 '17 at 0:23

High re-transmission percentage is a definitive sign of something being wrong. But unfortunately it isn't always a direct sign that congestion is the issue. If you could provide some packet captures, that would help us help you determine what the problem is.

I would also suggest running sets of 1000 pings throughout the day. Look at the resulting Round Trip Times (RTT) and the resulting Packet Loss %. Those each tell you something different. Typically, high RTT means congestion, and high Packet Loss indicates an unreliable path (which can also be due to a plethora of different reasons).

| improve this answer | |

This is not necessarily a network issue. If the new facility has other resource starvation (memory, processor availability, etc.) and the NICs are virtual, the packets could be dropped.

You can test if it's actually networking issue or processing issue by bringing up echo server and trying to saturate it with nc (under linux) sending random traffic to the port in increasingly large amounts. See if you get a throughput higher than your client. Then you might be dealing with a server which can't cope with the processing load. (might!!!)

It's still potentially a networking issue even if the saturation test doesn't produce the same packet loss, but, at least, if you'll produce more realistic simulation of networking traffic then just pings.

| improve this answer | |

Not necessarily a congestion in the network, because errors in the packet may also cuse retransmission since TCP is used

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.