Problem:
Recently I was migrating some Windows Server 2003 applications to new hardware and Windows Server 2008. The applications were mostly simple ASP.NET applications using either NHibernate or ADO.NET to communicate to a Windows Server 2003 x64 box running Sql Server 2005sp3.
Each of the new Win2k8 machines were having performance issue retrieving data from the database. After firing up Sql Profiler I was able to see that executing a simple statement like “SELECT * FROM Store” was taking over 5sec to return 40 rows. The slowness was the same in both ADO.NET and NHibernate apps. More research from that the WinForms apps running as admin were having the same issues. And executing the queries in SSMS showed same behavior.
So Win2k3 servers talking to the same database are running fast. Blowing my mind I found that using the Win2k8 servers to connect to a different Sql Server 2005sp2 on 32bit runs just fine (no delays). That’s right I can load the data onto a different server and see no delays!
If you are reading this you might be starting to form some theories. Both the Win2k3 and Win2k8 servers are on the same subnet.
At this point I requested help from the smart support guys from Microsoft. We verified that the Sql execution plans were not changing. We also verified the network settings on the database, Win2k3, and Win2k8 servers.
Next step netmon. After capturing and reviewing the netnom logs we were able to see that there were packets getting fragmented and there were long delays in sending the secondary packets. There are many newer features in Win2k8 to optimize the network performance (receive side scaling, tcp chimney offload, network direct memory access, and autotuning). Learn more here: http://support.microsoft.com/kb/951037
Root Cause:
In my situation the autotuning feature was trying to adjust the tcp receive window (RWIN) and was timing out waiting for an acknowledgment from the database server. It is possible that the router was holding onto the response packet, I wasn’t able to completely correlate all the send/receives.
Learn more about RWIN behavior here: http://www.nerdgrind.com/speed-up-windows-vista-network-performance-with-tcp-windows-tuning/2/
Resolution:
It is possible that we could have reconfigured the router to increase the frame sizes to prevent the packet fragmentation. It is also possible that change could have hidden the delays
The way I choose to resolve the issue was to turn off the autotuning with the following statement:
netsh interface tcp set global autotuning=disabled
Some network card drivers have the ability to control this setting via the advanced properties.







