SET NOCOUNT ON fa davvero molta differenza di prestazioni

Question

In questo article, l'autore suggerisce che è presente un overhead di materiale associato a SET NOCOUNT ON e che "Rimuovendo questo overhead aggiuntivo dalla rete si può migliorare notevolmente le prestazioni generali del database e applicazione "

L'autore fa riferimento a una modifica del modello di stored procedure predefinito dal 2000 al 2005 e suggerisce che" Microsoft ha persino realizzato il problema "che ha richiesto la modifica in questo modello.

Qualcuno ha prove concrete che supporta o rifiuta il guadagno di prestazioni richiesto con l'impostazione NOCOUNT ON.

Answer 1

L'ultimo collegamento nella mia domanda qui: "SET NOCOUNT ON usage" si riferisce a un article on it.

Dato quanto è banale, perché non lasciarlo e interrompere il client che elabora un altro set di risultati?

E senza SET NOCOUNT ON, NHibernate può rompere troppo (citato in questione)

Answer 2

ci sono scenari in cui SET NOCOUNT ON è obbligatoria. Quando si progetta un mid-level ad alte prestazioni basato sull'elaborazione asincrona sfruttando il pool di thread tramite i metodi BeginExecuteXXX di SqlClient, c'è un problema molto serio con i conteggi delle righe. I metodi BeginExecute vengono completati non appena il pacchetto di risposta viene restituito dal server. Tuttavia, quando viene richiamato un EndExecuteXXX, questo viene completato con richieste non di query al termine della chiamata. Ogni risposta di rowcount è una risposta. Durante l'elaborazione di procedure anche moderatamente complesse, il conteggio della prima riga potrebbe tornare in 5-10 ms, mentre la chiamata viene completata in 300-500 ms. Invece di richiamare la richiesta asincrona inviata dopo 500 ms, richiama dopo 5 ms e quindi i blocchi di callback in EndExecuteXXX per 495 ms. Il risultato è che le chiamate asincrone vengono completate prematuramente e bloccano un thread dal pool di thread nelle chiamate EndExecuteNonQuery. Questo porta alla fame di ThreadPool. Ho visto sistemi ad alte prestazioni migliorare il throughput da centinaia di chiamate al secondo a migliaia di chiamate al secondo semplicemente aggiungendo SET NOCOUNT ON, su scenari specifici.

Dato che per l'elaborazione di livello midle ad alta velocità/alto throughput le chiamate asincrone sono l'unico modo per andare, il NOCOUNT è praticamente un requisito obbligatorio.

Answer 3

Sono d'accordo che l'utilizzo di NOCOUNT è una grande idea. È una pessima idea aggiungerlo a tutto il codice eseguito in ogni SPROC o istruzione SQL dinamica.

Soprattutto se si parla di prestazioni elevate. TSQL NOCOUNT deve essere impostato in base alle necessità dal codice nel livello di accesso ai dati. Proprio come le transazioni e i livelli di blocco.

L'impostazione di queste cose ogni volta che si esegue l'SQL in esecuzione ogni volta non offre l'eccezionale incremento delle prestazioni che è possibile ottenere impostandole nel codice dell'applicazione di connessione.

Si ottengono prestazioni migliori scrivendo codice migliore non aggiungendo le istruzioni SET NOCOUNT a tutto il codice SQL.