Sql-server – Connection to localhost dramatically slower than to network server

Networkperformancesql serversql-server-2008-r2

I have an Excel VBA application that connects to a SQL Server 2008 R2 database through ADODB.

When I'm on the network at work, the connection is almost instantaneous. When I am at home working with a local copy of the database, the connection takes about 5 seconds. At first I thought the performance hit had to do with the queries, and even posted a question on Stackoverflow with that incorrect assumption: https://stackoverflow.com/q/10467876/138938

The connection is just as slow locally whether I specify "localhost" or a ".". It seems like my code is having a hard time resolving where exactly my localhost is. Is there something I should do with my hosts file or some other setting that I can modify to speed up my connection on my local machine?

What other thing should I look at to troubleshoot?

Thanks!

Best Answer

Try enabling TCP/IP on your local instance:

  • Open SQL Server Configuration Manager (mmc.exe -> [Ctl] + [M] -> Add "SQL Server Configuration Manager" snap-in)
  • Expand "SQL Server Network Configuration"
  • Click on "Protocols for MSSQLSERVER" (or whatever your local instance name is)
  • Set "TCP/IP" to Enabled

I just ran into this problem tonight. Contrary to @Aaron Bertrand's seemingly intuitive suggestion in the comments, having TCP/IP disabled was actually causing my delay. TCP/IP is disabled by default, so this is likely a common source of frustration for others, too.

I ran ProcMon.exe while connecting to a remote server and a local instance of SQL Server. I was using the Jet/ACE ODBC TraceSQLMode to debug the delay. TraceSQLMode writes to a text file every time an ODBC command is issued.

When connected to the remote server, seven commands were written to the text file in under one second total. With the local instance, there were almost exactly two seconds between each ODBC call.

I assume that the Jet/ACE ODBC driver was attempting to connect to the localhost via TCP/IP initially with every ODBC call. Since TCP/IP was disabled, this likely failed after a two-second timeout, at which point the Jet/ACE ODBC connection appears to have fallen back on Shared Memory access.

Enabling TCP/IP eliminated the two-second timeout delay, resulting in a massive performance increase (especially when making multiple calls to the database).

Related Question