Question

UPDATE: Please see the updates below, as I’m adding more information to the bottom as I run into it.

I’m working on setting up a new web server running Windows Server 2008, connecting to another Windows 2003 Server with SQL Server 2005. I’m running into some weird results when trying to run queries from the server to the SQL Server 2005 server. Basically, ever other query has a fixed 625 millisecond overhead if results are returned, but no overhead when it’s a non-query:

I’ll let my sample VB script code do the talking:

set cn = CreateObject("ADODB.Connection")
cn.Open "Provider=SQLNCLI;Server=thesqlserver;Integrated Security=SSPI;initial catalog=thedatabase"

t = Timer

for i = 1 to 20
    set rs = cn.Execute("select getdate()") //Note getting recordset here
    s = s & (timer - t) & VbNewLine
    t = Timer
next

for i = 1 to 20
    cn.Execute("select getdate()") //Note no recordset returned here
    s = s & (timer - t) & VbNewLine
    t = Timer
next

set fso = CreateObject("Scripting.FileSystemObject")
set file = fso.OpenTextFile("c:\results.txt", 2, True)

file.WriteLine(s)
file.Close

Here are the actual results:

First Set - Returning recordset
0
0.625
0
0.6640625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.6171875
Second Set - Non-query execution
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.015625
0
0
0
0
0

I’m baffled. Any help would be greatly appreciated.

UPDATE:

In response to Kevin’s answer, I tried running the same script directly from the SQL server. The result was zero overhead all the way down. The connection between the two servers is a crossover network cable connected to the second NICs of each server.

UPDATE:

New information. I tried changing the servername in the “Server=” argument, and when using the internal (crossover cable) IP, it went from 625 milliseconds every even request, to 4,550 milliseconds ever even request (with the odd requests still at zero). Then, changing it to the public IP made the overhead go away completely! I must have something configured incorrectly on the internal NIC.

UPDATE:

Doing a Wireshark trace on the network activity, it appears the even requests are doing some sort of Windows challenge/response, and that’s hanging. These servers are not on a domain, and I’m using integrated security as shown above. However, again, using integrated security is fine as long as I’m hitting the external IP. Also, removing integrated security, and explicitly providing credentials when using the internal IP also gets rid of the overhead.

Answer 1

For now, the only solution I can find is to reference the external IP vs. the internal IP. I’m not sure if this has any performance impact (i.e. is the route the packets take longer now), but at least it’s working.