ODBC Win2K3 performance problem

[aquila125]

We have a program that uses an ODBC connection to connect to a SQL Server (on a Windows 2K3 Std Server).
As long as the application is running on a Windows 2000 or Windows XP machine, performance is ok. But when we install the program on a Windows 2K3 (for later use through Terminal Services), the performance drops.. alot...
I'm not an ODBC specialist, but we narrowed the problem to the Named Pipes/TCPIP settings of the ODBC connection. When we use Named Pipes, all works fine, but when we use the TCP/IP option, it turns nasty. The transfer rate is constant with Named Pipes, but with TCP/IP it has several random drops.. Using Named Pipes is only an option in our test environment...

Is this a know issue, or are we doing something wrong?

thanks!

 

[aquila125]

Hi all,

we found a solution.. the ODBC we were using was located in the System DSN, if we moved it to the User DSN, the performance was good.

This is pretty strange, since login in locally on the TS Server gave us the same performance problems..

Is there a difference between XP and 2003 in handling System and User DSN ?

 

[beleyrs]

aquila125, can you elaborate? I am seeing a similar issue with TCP DSN on Win2003. Did you create a user dsn for every user that connects to the SQL Server?

 

[aquila125]

We've found the problem.. It had to do with the new TCP/IP stack in Windows 2003. Normally, for every packet sent, a ACK packet is returned. In Win2K3 this has changed. Not every packet is answered with an ACK packet.
Changing this behaviour to the old one (by adding a Registry key) fixed our problem.

The fact that it worked for a user dsn and not for a system dsn has to do with the buggy way Windows works with those dsn.. (some changes are not made when you would expect them too..)

If you need more information, just let me know.. I can lookup the registry key...

 

[beleyrs]

if you don't mind...i'd like to look at it for consideration.

we have solved a slow down but it was an application specific issue, however, performance still seems to be lacking...

thanks!

 

[aquila125]

This is the reply we got from Microsoft:

Analyzing the trace shows numerous delayed acknowldges which means much time is lost by waiting on packets that will not come. to change this behaviour it is best to acknowledge every packet.
Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>
Entry: TcpAckFrequency
Value Type: REG_DWORD, number
Valid Range: 0-255
Default: 2 <===============change this to 1




good luck...

 

[Stevehewitt]

Just FYI - the reason Win2k3 Server doesn't respond is to do with protections against DoS attacks.
This time is really is a feature and not a bug!

Steve.

"They have the internet on computers now!" - Homer Simpson