I'd like some opinions on a wireshark capture between a web server and SQL database server that takes place over our WAN. This is east coast to west coast. We are trying to troubleshoot issues with slow performance on this web application. It was developed in house. We already know we have some issues with our WAN connection to this location from time to time and also looking into that. I haven't found in issues on the LAN yet. Also, there are other dependencies but this seems to be the main bottleneck since it's the only one cross-country.
I'm not a packet guru, I do know the fundamentals of TCP. I'm seeing a lot of ACK's with no SYN's and multiple ACK's in a row. Is this a bad capture? Also, it's saturated with reassembled PDUs. The average MS for this connection is 90-100, which I know might be out of the range of tolerance for SQL and could be causing the problem. Can anyone take look at this capture and shed some light on what they're seeing?
asked 30 Aug '15, 13:44
edited 30 Aug '15, 13:45
To me it looks like your application is not well designed to work over a WAN. Take a look at TCP stream 9 (the only one with some data to transmit). The client sends a SELECT and gets the answer pretty fast. But then it waits for ~ 2.5 seconds before it sends the next SELECT. These seconds wait time add up to a lot of "dead wait time" with the result, that the whole communication takes longer than it should.
As you can see. Between the SELECT and the last ACK for that request, there is a time delta of a few 100 ms, which is O.K. for a WAN link, especially as the SELECT statement is pretty large (~ 6KB).
However between the last ACK and the next SELECT, there is a pause of ~2.5 seconds!!
You can see that in the TCP Stream graph as well.
Please ask your developers why there is a pause of n seconds between the SELECT statements, as that’s causing the whole problem!
++ UPDATE ++
answered 30 Aug ‘15, 14:09
Kurt Knochner ♦
edited 30 Aug ‘15, 14:25