|
Hello Bill,
Thank you for the reply.
<snip>
|I take this to mean that the application server (not the SQL server) is being stated to be the bottleneck. Is |this correct ?
Yes, it appears to be a limitation in the way the SQL client is handling data received.
|That being said, is it possible to post an extract of the capture ?
Yes, I can post or email you an extract of the capture. I'm just not sure how to post it on this forum and what information I should remove. Do I just attach an export to the email or is there an upload feature?
|On a broader note: I would think that the company providing the report would/should provide details (traces, |response time analysis, test results, etc) to explain and substantiate their conclusions. Did they indicate the |existence of a network problem ?
No on the network issue. Both hosts reside on the same Cisco 6509 switch using 1Gb NIC's. And yes, they provided a nice report with graphs and charts and the following observations/recommendations related to this issue:
1) AppServer (WAPPBI01)TCP Receive Window is regularly dropping below the full MSS value 1460.
2) The SQL server (WDBBI01)then waits (up to 25ms) for the receivers TCP Receive window to update before continuing to transfer.
3) The event was seem to occur more than 90 times in less than a 3 minutes during a single data transfer.
4) WAPPBI01 may not have the resource availability required to adequately support this application delivery. However, since this event appears to occur regularly and systematically, the most likely source of this slow application delivery data transfer resides with the SQL client software residing on the AppServer (WAPPBI01).
5) Develop a comprehensive list of services that "should be" running on the AppServer (WAPPBI01)and associate each service with it's corresponding TCP port. ***We have done this***
6) Track service usage through ongoing monitoring of TCP session statistics.
7) Disable services that are not necessary for successful application delivery.
8) Ensure other systems are not inadvertently configured to communicate over TCP ports that are not in use.
Lastly some statistics on an average capture. Approx. 1 minute, 100 MB capture file, 107915 frames, 36478 out-of-order warnings and 16813 DUP Ack notes.
Thank you,
Michael
| 