Det finns scenarier där SET NOCOUNT ON är obligatoriskt. När man designar en högpresterande mellannivå baserat på asynkron bearbetning som utnyttjar trådpoolen via SqlClients BeginExecuteXXX-metoder, finns det ett mycket allvarligt problem med radantalet. BeginExecute-metoderna slutförs så snart som den första svarspaketet returneras av servern. Men när en EndExecuteXXX anropas, slutförs detta på icke-förfrågningar när samtalet är klart. Varje radantalsvar är ett svar. Vid bearbetning av även måttligt komplexa procedurer kan antalet första rader komma tillbaka efter 5-10 ms, medan samtalet slutförs efter 300-500 ms. Istället för att få den inlämnade asynkrona begäran att ringa tillbaka efter 500 ms, ringer den tillbaka efter 5 ms och sedan blockerar återuppringningen i EndExecuteXXX i 495 ms. Resultatet är att asynkrona anrop slutförs i förtid och blockerar en tråd från trådpoolen i EndExecuteNonQuery-anropen. Detta leder till ThreadPool-svält. Jag har sett högpresterande system förbättra genomströmningen från hundratals samtal per sekund till tusentals samtal per sekund helt enkelt genom att lägga till SET NOCOUNT ON, i specifika scenarier.
Med tanke på att för bearbetning av hög skala/hög genomströmning är asynkrona samtal den enda vägen att gå, är NOCOUNT i stort sett ett obligatoriskt krav.