Server Response Time is slow
Trying to figure out why this server slows down and takes 24 sec. to reply packet capture can be found https://drive.google.com/file/d/14spZ...
Trying to figure out why this server slows down and takes 24 sec. to reply packet capture can be found https://drive.google.com/file/d/14spZ...
Hi Musky,
I don't see anything "wrong" in the capture but there is a "story" to tell.
Since 192.168.136.43 initiates the TCP connection to 10.124.196.83 I'll call the former host the client and the later the server.
I don't know what application this is but it looks like the server (10.124.196.83) is waiting for something that never comes or something that takes a long time to get.
The server (10.124.196.83) ACKs frames 8-9 sent by the client right away.
These frames may contain a request of sort that the server needs to "fulfill".
In order to do so, the server may have to lookup records in a database or query some other host(s) for information or authentication. (LDAP, DNS, RADIUS, etc.)
This seems to fail for some reason. The server keeps sending the same data back to the client over and over while waiting 23-24 seconds between tries.
The server tries six (6) times and on the seventh the query either works or the server gives up. (Data changes in frame 23.)
The client then closes the connection (rudely?) with TCP RST.
I would focus on server 10.124.196.83 and see if it times out doing something else to serve 192.168.136.43.
Hope that helps.
Cheers,
JFD
Asked: 2019-08-05 01:57:27 +0000
Seen: 404 times
Last updated: Aug 08 '19
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Do you have more information on where this capture was taken? I don't see Window Scale option in TCP SYN segments. (SYN and SYN/ACK) I find this odd for a modern TCP/IP stack.
Capture was taken at the server side the packet capture was sliced when saved here is the link to the capture showing the first 77 bytes https://drive.google.com/drive/folder... what I find strange is every second packet both directions has the push bit set
I realize that you are probably trying to protect confidential or proprietary information, but your first file (in the question) has been truncated so severely that it's unlikely anyone will be able to draw any conclusions. Your second file, in the comment, returns "Access Denied" and can't be downloaded.
Here is the link https://drive.google.com/file/d/1kVFD...
I am curious starting at packet 11 the delta is 23 sec.