Er zijn scenario's waarin SET NOCOUNT ON verplicht is. Bij het ontwerpen van een high-performance middenlaag op basis van asynchrone verwerking waarbij gebruik wordt gemaakt van de threadpool via de BeginExecuteXXX-methoden van SqlClient, is er een zeer ernstig probleem met het aantal rijen. De BeginExecute-methoden zijn voltooid zodra de eerste antwoordpakket wordt geretourneerd door de server. Maar wanneer een EndExecuteXXX wordt aangeroepen, wordt dit voltooid op niet-queryverzoeken wanneer de aanroep is voltooid. Elk rijtellingsantwoord is een antwoord. Bij het verwerken van zelfs matig complexe procedures kan het aantal eerste rijen terugkomen in 5-10 ms, terwijl het gesprek in 300-500 ms wordt voltooid. In plaats van dat het ingediende async-verzoek na 500 ms wordt teruggebeld, wordt het na 5 ms teruggebeld en worden de terugbelblokkeringen in de EndExecuteXXX gedurende 495 ms. Het resultaat is dat asynchrone aanroepen voortijdig worden voltooid en een thread uit de threadpool in de EndExecuteNonQuery-aanroepen blokkeren. Dit leidt tot verhongering van ThreadPool. Ik heb gezien dat high-performance systemen de doorvoer hebben verbeterd van honderden oproepen per seconde naar duizenden oproepen per seconde door simpelweg het SET NOCOUNT ON toe te voegen voor specifieke scenario's.
Gezien het feit dat voor high scale/high throughput verwerking van de middenlaag de enige manier is om te gaan, is de NOCOUNT vrijwel een verplichte vereiste.