I have a server that is running and the user says that the application is running very slowly. I did a capture and I found that the window size for the server was very small, but there were no window updates, no zero windows, and no full windows. I suggested that he optimize the TCP/IP setting on the server to improve the performance. I will paste a few frames so you can get an idea of what I am talking about. Thanks for the help. This question is marked "community wiki". asked 07 Apr '13, 17:08  Ernest Johnson edited 07 Apr '13, 18:32  cmaynard ♦♦ |
2 Answers:
You say:
in this capture file, there is only SQL traffic. So, if your application is using SQL and the user reports a slow response, it's rather due to the nature of the application (sending small requests in a sequence, waiting, sending again), instead of a TCP window size problem. Use this display filter: Can you please add more information about your application and what exactly is slow within the application. Regards answered 08 Apr '13, 07:05  Kurt Knochner ♦ |
You are not seeing the true window sizes because window scaling is in use and you did not capture the TCP three-way handshake. Window scaling is negotiated during the three-way handshake. You need to run your capture again and this time capture the connection establishment process. In frame 1, the receiver advertises a window size of 245, but the sender immediately transmits two packets with 1460 bytes each. It would not do that if the window size was really 245 bytes. If you expand the TCP portion of frame 1 in the Packet Details pane, under "[Calculated window size: 245]" you will see "[Window size scaling factor: -1 (unknown)]". This means that Wireshark missed the three-way handshake and does not know what scaling factor the two hosts are using and so is not able to calculate the true window size. See RFC 1323 for details on the window scale option. answered 07 Apr '13, 18:03  Jim Aragon Thanks much Jim will do (07 Apr '13, 21:15) Ernest Johnson Jim I took a second trace, a small piece to catch the 1 packet, I did not get what I was expecting to see. I don’t know what is up with this trace. (07 Apr '13, 21:51) Ernest Johnson The trace does not contain a TCP three way handshake. You should try to start the capture and then start the application, otherwise you'll end up with packets of an already established connection. You can only see the scaling factor in the SYN packets, so you need to capture the handshake packets. (08 Apr '13, 03:04) Jasper ♦♦ thanks for th information i will do another capture (16 Apr '13, 21:35) Ernest Johnson Ernest Looking at file you uploaded I think you might want to look at server logs and troubleshoot there. When a batch or remote procedure call (RPC) is submitted to SQL Server, the server checks for the validity and correctness of the query plan before it begins executing. If one of these checks fails, the batch may have to be compiled again to produce a different query plan. Such compilations are known as recompilations. Could you please tell me more about your platform. Also the sql-batch query on Wireshark capture is size limited can this expanded to include more data? (18 Apr '13, 21:18) Jeffrey DeSalvo Thanks all for the help (28 Apr '13, 16:53) Ernest Johnson showing 5 of 6 show 1 more comments |
Kurt
first tds.type eq 1 https://www.cloudshark.org/captures/a31fe4fc12faet
I do see high Delta times b th servers and it is all sql traffic. I don’t know much about this application all i know is that it is and server communication with the SQL server. Don’t know much more about it.
second display filter tds.type eq 4
https://www.cloudshark.org/captures/03dc5369261
The trace is displaying TCP retransmissions any idea what could be causing the application to be degraded, the application is not running very well. In performance monitor that was given to me I see a burst of traffic and then you get a drop almost to zero then a burst and it just repeats until the application transaction is complete. This is a small capture of a 3 gig trace. Any ideals what may be going on? Thanks Kurt
https://www.cloudshark.org/captures/acd1ff11a4c7
krut
Here is a larger sample of the trace that occurs at the time of the application run that may help you get a better understanding of what is going on
I hope it is not confusing
Neither of these links (first two) do work
without knowledge about the nature of the application (interactive, mass data up-/download, etc.) it's hard to make any assumptions about possible performance problems.
That traffic pattern could be caused by the client (not sending the requests fast enough - due to data processing), or the server not responding fast enough (although the capture file does not show this behavior).
As I said, without knowledge about the nature of the application its hard to make any assumptions just by staring at the network trace ;-)
So, can you please add some details about the application and possibly a trace of a session that is rated as 'fast responding' by the users.
Regarding the last capture file ( https://www.cloudshark.org/captures/acd1ff11a4c7 ).
Please use this display filter:
tcp.stream eq 7and then take a look at the traffic pattern. There is a long sequence of REQUEST (SQL batch or RPC call) and RESPONSE. The first sequence lasts 14 seconds (Frame: 71302)! without much delay. Then there is nothing for 30 seconds, then some TCP keepalives and then another sequence for 2 seconds (in this capture file).I have seen similar behavior with GIS systems (Geoinformation systems) that did hundreds and thousands of SQL SELETCs to load tiny objects. Well, that will last very long and it's usually a design error in the application to do it that way.
The traffic pattern in your capture file reminds me pretty much on such a GIS system.
The lack of the SYN, SYN/ACK, ACK has nothing to do with the application design. Every TCP connection starts with SYN, SYN/ACK, ACK. Those packets are not in your capture file because you are not capturing the start of the connection. The TCP connection is already in place when you begin capturing. Again, if you expand the Transmission Control Protocol portion of the packet, you will see "[Window size scaling factor: -1 (unknown)]."
The "Win=256" is not a problem because 256 is not the true window size. Because the connection establishment is not present in the capture file, Wireshark is not able to calculate the true window size. I really don't think window size is your issue. I don't see any place in your capture file where the window size drops to zero, and if you add a Window Size custom column and sort on that column, you will see that the packets with the very smallest window sizes are not preceded by any significant delays.
"Len=0" is also not a problem. This simply means that there is no data in the packet, which is generally because the packet is an acknowledgment only. If you apply a display filter of "tcp.len==0" and then sort on the source IP address column, you will see that out of 17,504 packets with a tcp.len of 0, 17,500 are from 10.97.35.214, because 17.97.35.214 is the receiver, so it is mostly acknowledging data, not sending data.