En realidad, SET NOCOUNT ON hace una diferencia de rendimiento

Question

En este article, el autor sugiere que hay gastos generales asociados con SET NOCOUNT ON y que "Al eliminar esta sobrecarga adicional de la red, puede mejorar enormemente el rendimiento general de su base de datos y la aplicación "

El autor hace referencia a un cambio en la plantilla de procedimiento almacenado predeterminado de 2000 a 2005 y sugiere que" Microsoft incluso se dio cuenta del problema "que provocó el cambio en esta plantilla.

¿Alguien tiene pruebas fehacientes de que admite o rechaza la ganancia de rendimiento reclamada al configurar NOCOUNT ON.

Answer 1

El último enlace en mi pregunta aquí: "SET NOCOUNT ON usage" se refiere a un article on it.

Dado lo trivial que es, ¿por qué no lo deja y detiene al cliente procesando otro conjunto de resultados?

Y sin SET NOCOUNT ON, NHibernate puede romper también (se menciona en cuestión)

Answer 2

hay escenarios donde SET NOCOUNT ON es obligatorio. Al diseñar un nivel intermedio de alto rendimiento basado en el procesamiento asincrónico aprovechando 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 servidor devuelve el primer paquete de respuesta . Pero cuando se invoca un EndExecuteXXX, este 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 procedimientos incluso moderadamente complejos, el recuento de la primera fila podría regresar en 5-10 ms, mientras que la llamada se completa en 300-500 ms. En lugar de hacer que la solicitud asincrónica enviada vuelva a llamar después de 500 ms, devuelve la llamada después de 5 ms y luego los bloques de devolución de llamada en el EndExecuteXXX durante 495 ms. El resultado es que las llamadas asincrónicas se completan prematuramente y bloquean un hilo 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.

Teniendo en cuenta que para el procesamiento de nivel medio de alta escala/alto rendimiento, las llamadas asíncronas son la única manera de hacerlo, la NOCOUNT es prácticamente un requisito obligatorio.

Answer 3

Acepto que usar NOCOUNT es una gran idea. Es una idea terrible agregarlo a todos los códigos ejecutados en cada instrucción SPROC o SQL dinámico.

Especialmente si habla de alto rendimiento. El código en la capa de acceso a datos debe establecer TSQL NOCOUNT según sea necesario. Al igual que las transacciones y los niveles de bloqueo.

Establecer estas cosas cada vez en el SQL de ejecución que se ejecutará cada vez no le da la gran mejora de rendimiento que podría obtener configurándolos en el código de la aplicación de conexión.

Se obtiene un mejor rendimiento escribiendo mejor código no agregando sentencias SET NOCOUNT a todo su SQL.