Slowness of SQL client-server app

edit

If generating the report directly on the server is taking 1 min 30 sec, then chances are high that there are a lot of individual queries being made to generate the report. When generating the report over the network, a round-trip time is added to each individual query. So if there were 50000 queries and the roundtrip time was 2 ms, 100000 ms are added to the time it takes to generate the report.

On top of that, there can be a low "fetch size", this means that for one query, the result is not sent in one response, but has to be fetched block by block, adding a roundtrip for each block, making the problem even worse.

Have a look at your capture file and check how many times you see a TCP time delta of approximately the initial roundtrip time (calculated from the 3 way handshake and added to each TCP packet for your reference). Then do the math on how much extra delay is introduced from these roundtrip times and if it matches the time difference between running the report locally on the server or remotely from the client.

could be possible that this is a reason why app works slow ??

Not by itself. "TCP segment of a reassembled PDU" is NOT an error indication; it's merely a simple statement that, at least as Wireshark's dissection code sees it, it appears to be the case that there's a packet, for some protocol running on top of TCP, on that side of the TCP connection that doesn't neatly fit into a single TCP segment, this packet contains one of those TCP segments, and it doesn't, as of when it first saw that packet, have all the data for that packet, so it can't, as of that point, reassemble the packet.

If those two frames have, in the "TCP" part of the detailed dissection pane, a "Reassembled PDU in frame N", for some value of N, then the higher-level packet was successfully reassembled, and frame N will show it. In that case, "TCP segment of a reassembled PDU" does not indicate any problem - the problem lies elsewhere.

Otherwise, the problem might be that not all the TCP segments for that packet are in the capture. That could either be the result of the capture process not capturing all packets received by the machine on which the capture was done, in which case it's a problem with capturing, not a problem with the network, or the result of the packets not seen having been sent by the server but not by the machine on which the capture was done, which could be the result of a network problem.

If that's the case, you might try checking the preferences for the TCP protocol (pop up the Preferences dialog - Edit > Preferences on most operating systems, Wireshark > Preferences on macOS), open up the "Protocols" item, and look for "TCP". If the "Analyze TCP sequence numbers" preference isn't enabled (with a check in its checkbox), enable it and click "OK". If it is enabled, leave it alone.

Then look at the packets in that TCP connection near those two frames and see if, in the packet details, there are any "SEQ/ACK Analysis" items indicating problems, such as, for example,, "Previous segment(s) not captured".

If there are any indications of out-of-order segments, make sure that the TCP preference "Reassemble out-of-order segments" is enabled; if not, enable it and see if that makes it possible for the dissector to reassemble the packet, so that frames 38123 and 38124 are part of that packet.