SQL 2005 connection using classic ADO from Windows 2008 yields odd performance
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 Window开发者_高级运维s 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.
There is an overhead in setting up the recordset object but does seem 625ms is a bit steep, it might be down to having to destroy the existing recordset and put the new one in.
Either way if I’m performing an action query and don’t need the recordset I always use the extra option adExecuteNoRecords so that no recordset is setup and the query will execute faster.
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.
精彩评论