First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

argue why the slow transfer is slow

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

slow --> https://www.cloudshark.org/captures/5... fast ---> https://www.cloudshark.org/captures/0...

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?

soochi's avatar
67
soochi
asked 2018-02-15 18:21:28 +0000, updated 2018-02-15 20:21:37 +0000
edit flag offensive 0 remove flag close merge delete

Comments

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's avatar Packet_vlad (2018-02-16 11:09:02 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

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....?

Christian_R's avatar
2.1k
Christian_R
answered 2018-02-16 19:24:53 +0000, updated 2018-02-17 22:48:36 +0000
edit flag offensive 0 remove flag delete link
more

Comments

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's avatar soochi (2018-02-17 21:19:29 +0000) edit
more
  • delete

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's avatar Christian_R (2018-02-19 10:06:51 +0000) edit
more
  • delete

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's avatar Packet_vlad (2018-02-19 12:02:50 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer