Linq-to-SQL and sp_reset_connection

Question

I have a .NET 4.0 Winform and a .NET 4.0 Windows Service which both connect to a SQL 2005/2008 database through LINQ to SQL. It runs nice and fast on our test environment with a perfect clone of production data, but on the Production environment, it runs really slowly and has low CPU usage and bandwidth usage. I also noticed hundreds of SQL timeouts a day, even for the smallest queries on a well-indexed database. So I fired up the Profiler...

I found that sp_reset_connection accounted for one third of total SQL CPU duration and 90% of all total SQL calls during a 10-minute capture under load.

• I have tried disabling & enabling connection pooling and fiddling with the number of allowed connections and connection timeouts in the connection string. None have had any effect.
• I have been replacing my LINQ queries with ADO.NET queries as I come across them. These old ADO.NET queries never time out. Only the LINQ ones.
• I have noticed other major performance issues on that server, but I'm not sure how to approach the subject with the customer's sysadmin.

• I have Admin access on the Application server the service runs on. I have next to no access on the terminal server where they run the Winform, nor to the SQL server.

• What causes sp_reset_connection to run so often?

• Is there a way to circumvent these calls without tearing all the LINQ out of my application?
• Is there a way to reduce the number of calls to this stored procedure?
• Is there a way to reduce the amount of processor time the SQL server needs for these calls?
• Will I mess anything else up if I leave pooling disabled and replace that stored proc with, say, an empty one?

Answer 1

Found some other pages about this, one suggested this:

For your connection reset, open your DataContext connection before working with it and close it at the end.

db.Connection.Open()
... work...
db.Connection.Close()