Hay escenarios donde SET NOCOUNT ON es obligatorio. Al diseñar un nivel medio de alto rendimiento basado en el procesamiento asincrónico que aprovecha el grupo de subprocesos a través de los métodos BeginExecuteXXX de SqlClient, existe un problema muy grave con los recuentos de filas. Los métodos BeginExecute se completan tan pronto como el primero el paquete de respuesta es devuelto por el servidor. Pero cuando se invoca un EndExecuteXXX, esto se completa en las solicitudes que no son de consulta cuando se completa la llamada. Cada respuesta de recuento de filas es una respuesta. Al procesar incluso procedimientos moderadamente complejos, el recuento de la primera fila podría volver en 5-10 ms, mientras que la llamada se completa en 300-500 ms. En lugar de que la solicitud asincrónica enviada devuelva la llamada después de 500 ms, vuelve a llamar después de 5 ms y luego la devolución de llamada se bloquea en EndExecuteXXX durante 495 ms. El resultado es que las llamadas asincrónicas se completan prematuramente y bloquean un subproceso del grupo de subprocesos en las llamadas EndExecuteNonQuery. Esto lleva a la inanición de ThreadPool. He visto sistemas de alto rendimiento que mejoran el rendimiento de cientos de llamadas por segundo a miles de llamadas por segundo simplemente agregando SET NOCOUNT ON, en escenarios específicos.
Dado que para el procesamiento de nivel medio de alta escala/alto rendimiento las llamadas asincrónicas son la única forma de hacerlo, NOCOUNT es prácticamente un requisito obligatorio.
