 | 1 | initial version |
It's a little hard to say without knowing exactly what is going, but what I find interesting is that if you look at the conversations that happen on TCP port 85 you can see that one side (172.29.77.183) is sending data that gets acknowledged (54 byte packet from 172.22.242.89), but then it takes at least 1 second to send the answer back each time (easy to find by looking for the TCP push flag, also from 172.22.242.89) - in case of the bad connection i've seen up to 17 seconds delay between the ACK and the PSH ACK.
It looks to me like the application processing time on 172.22.242.89 is really not that good (= performing well). From my gut feeling it looks more like a delay on that node than a network problem. Also, seeing TCP Keep-Alive packets is an indicator one node is waiting for the other.
To further investigate the non-anonymized packets I'd recommend you isolate the TCP conversations one by one (either via right click -> Conversation Filter -> TCP, or via Statistics -> Conversations -> right click). You should add a column "Delta Time Displayed" to your setup (unless you already have it, of course) and track where the delays are for each TCP connection.
| | 2 | No.2 Revision |
It's a little hard to say without knowing exactly what is going, but what I find interesting is that if you look at the conversations that happen on TCP port 85 you can see that one side (172.29.77.183) is sending data that gets acknowledged (54 (usually a 54 byte packet from 172.22.242.89), but then it takes at least 1 second to send the answer back each time (easy to find by looking for the TCP push flag, also from 172.22.242.89) - in case of the bad connection i've seen up to 17 19 seconds delay between the ACK and the PSH ACK.
It looks to me like the application processing time on 172.22.242.89 is really not that good (= performing well). From my gut feeling it looks more like a delay on that node than a network problem. Also, seeing TCP Keep-Alive packets is an indicator one node is waiting for the other.
To further investigate the non-anonymized packets I'd recommend you isolate the TCP conversations one by one (either via right click -> Conversation Filter -> TCP, or via Statistics -> Conversations -> right click). You should add a column "Delta Time Displayed" to your setup (unless you already have it, of course) and track where the delays are for each TCP connection.
