Linq-to-SQL e sp_reset_connection

Question

Ho un .NET 4.0 Winform e un .NET 4.0 Windows Service che si collegano entrambi a un database SQL 2005/2008 tramite LINQ a SQL. Funziona in modo piacevole e veloce sul nostro ambiente di test con un clone perfetto di dati di produzione, ma nell'ambiente di produzione, funziona molto lentamente e ha un utilizzo ridotto della CPU e l'utilizzo della larghezza di banda. Ho notato anche centinaia di timeout SQL al giorno, anche per le query più piccole su un database ben indicizzato. Così ho sparato il Profiler ...

ho scoperto che sp_reset_connection rappresentato per un terzo della durata totale della CPU di SQL e il 90% di tutte le chiamate totali SQL durante una cattura 10 minuti sotto carico.

• Ho provato disabilitando & abilitazione pool di connessioni e giocherellare con il numero di connessioni consentite e timeout di connessione nella stringa di connessione. Nessuno ha avuto alcun effetto.
• Ho sostituito le mie query LINQ con le query ADO.NET mentre le trovo. Queste vecchie query ADO.NET non scadono mai. Solo quelli LINQ.
• Ho notato altri importanti problemi di prestazioni su quel server, ma non sono sicuro di come affrontare l'argomento con il sysadmin del cliente.

• Ho accesso di amministratore sul server applicazioni su cui è in esecuzione il servizio. Non ho più accesso al server terminal su cui eseguono Winform, né al server SQL.

• Che cosa causa il funzionamento dello sp_reset_connection?

• C'è un modo per aggirare queste chiamate senza strappare tutto il LINQ dalla mia applicazione?
• C'è un modo per ridurre il numero di chiamate a questa stored procedure?
• C'è un modo per ridurre la quantità di tempo del processore di cui il server SQL ha bisogno per queste chiamate?
• Posso rovinare qualcos'altro se lascio il pool disabilitato e sostituire quello memorizzato con, diciamo, uno vuoto?

Answer 1

trovato alcune altre pagine su questo, uno suggerito questo:

Per la vostra ripristino della connessione, aprire la vostra connessione DataContext prima di lavorare con esso e chiudono alla fine.

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

Answer 2

sp_reset_connection si verifica quando uno SQLConnection ritorna al pool di connessioni, ora questo non dovrebbe essere un problema.

ma ora la domanda è: perché ricevi timeout? è il server sql che non può far fronte alla quantità di transazioni o è che il pool di connessioni si svuota, non ha mai usato Linq-to-sql ma assicurati di disporre di tutto ciò che puoi disporre quando hai finito con gli oggetti ...

Edit: il pool di connessioni è lì per un motivo che la rimozione sarà likly peggiorare le prestazioni e la rimozione "sp_reset_connection" vi darà errori strani come i dati saranno riportati al successivo utente della connessione ...

per ridurre la quantità di sp_reset_connection l'unico modo che puoi fare è provare a riutilizzare la stessa connessione per quante più query possibili!