Ask Your Question

argue why the slow transfer is slow

asked 2018-02-15 18:21:28 +0000

soochi gravatar image

updated 2018-02-15 20:21:37 +0000

Hello Friends, My task is to find out why one trace is slow.

slow --> fast --->

Both the capture is made near the server via TAPs.

From my findings the slow transfer is slow because of the nature of the application. The application sends some data to sever and the server only answers after resumption of this application data. Both the traces have the same pattern of packet flow in the sense that the server waits still the client sends some data. As the RTT of the slow transfer is high the total duration is longer. Can anyone find some other reason for this?

I could calculate the slow transfer took 12 seconds as there are 253 packets send by the client which took the time equal or grater than to RTT which is 2530ms. There are 2 packets sent after the re transmission time out which is took 2734 ms. Thus the network time spend by the slow transfer is 5264ms. The time which the server took till the capture point is not taken into account. Did i miss something?

edit retag flag offensive close merge delete


Cool case. Could you please add some details regarding network environment? Server packets TTL is 59, how close to the server are you? What App type is it? Looking on PSH flags I see the server is sending a set of different-size objects/responses.

Two gaps in "slow transfer" are very interesting (packets 230, 513 areas). For me these look like TCP-related gaps (TCP packet train tail drop?). Retransmission timer of 1,5 sec isn't normal too, is it something between TAP and the server?

Packet_vlad gravatar imagePacket_vlad ( 2018-02-16 11:09:02 +0000 )edit

1 Answer

Sort by » oldest newest most voted

answered 2018-02-16 19:24:53 +0000

Christian_R gravatar image

updated 2018-02-17 22:48:36 +0000

Yes nice trace. The reason for the slowness is that the server has to retransmit some frames, by time. For example It seems that packet 218 didn´t make it to the client. And as it contains the PSH bit, both devices are waiting on each other. It is more or less a deadlock at that moment. Which will cost you 1,5 seconds. Don´t know why the RTO is so high....?

edit flag offensive delete link more


hi Christian and Vlad,

The application which is in the trace is a SAP transaction run by an identical script on two different computers. One of this computer is near to the server located within the DC. The other computer is separated from the server via a WAN connection which per providers SLA involves maximum 10ms RTT.

The packet drop causes very near to the computer itself. This problem could be cured by the network guys but the basic problem what my client faces is caused due to the chattiness of the application. Due to this chattiness and high RTT the performance is impacted.

The client later informed me that he found some improper implementation of codes which inappropriately queries the SAP application server, like not sending multiple queries in a single request.

Thanks for your comments... regards Sooraj

soochi gravatar imagesoochi ( 2018-02-17 21:19:29 +0000 )edit

I would say, if you eleminate the packet loss, it hepls you a lot, as it is more less the root cause here. And if you find out why the the RTO is 1,5sec, that helps you, too (Expected is somewhat around 0-300ms).

Tuning the application is always good, as it can also improve the FAST example.

Christian_R gravatar imageChristian_R ( 2018-02-19 10:06:51 +0000 )edit

Agree with that. You can't guarantee total absence of packet loss in WAN environment even if you have 10ms SLA. One time this is client computer dropping packets, another time this is something else. You can get sporadic performance drop as a result. It's better to investigate it while you know that fact.

Packet_vlad gravatar imagePacket_vlad ( 2018-02-19 12:02:50 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-02-15 18:21:28 +0000

Seen: 716 times

Last updated: Feb 17 '18