Действительно УСТАНАВЛИВАЕТ NOCOUNT НА, действительно делают так большую часть различия в производительности
В этой статье автор предполагает, что существует существенно служебный связанный с SET NOCOUNT ON и это "Путем удаления этих дополнительных издержек из сети это может значительно улучшить общую производительность для базы данных и приложения"
Автор ссылается на изменение в шаблоне хранимой процедуры по умолчанию с 2000 до 2005 и предполагает, что "Microsoft даже поняла проблему", которая запросила изменение в этом шаблоне.
Делает у кого-то есть веское доказательство, что или поддержки или опровергают требуемое увеличение производительности с установкой NOCOUNT ON.
2 ответа
Последняя ссылка в моем вопросе здесь: « SET NOCOUNT ON usage » относится к статье об этом .
Учитывая, насколько это тривиально почему бы не оставить его и не остановить обработку клиентом другого набора результатов?
А без SET NOCOUNT ON nHibernate тоже может сломаться (упоминается в вопросе)
Существуют сценарии, в которых параметр SET NOCOUNT ON является обязательным. При проектировании высокопроизводительного среднего уровня на основе асинхронной обработки с использованием пула потоков с помощью методов BeginExecuteXXX SqlClient возникает очень серьезная проблема с подсчетом строк. Методы BeginExecute завершаются, как только сервер возвращает первый пакет ответа . Но когда вызывается EndExecuteXXX, это завершается для запросов, не связанных с запросом, когда вызов завершен. Каждый ответ rowcount - это ответ. При обработке даже умеренно сложных процедур подсчет первой строки может вернуться через 5-10 мс, в то время как вызов завершается за 300-500 мс. Вместо того, чтобы отправлять ответный вызов асинхронного запроса через 500 мс, он выполняет обратный вызов через 5 мс, а затем блокирует обратный вызов в EndExecuteXXX в течение 495 мс. В результате асинхронные вызовы завершаются преждевременно и блокируют поток из пула потоков в вызовах EndExecuteNonQuery. Это приводит к голоданию ThreadPool. Я видел, как высокопроизводительные системы улучшают пропускную способность с сотен вызовов в секунду до тысяч вызовов в секунду, просто добавляя SET NOCOUNT ON в определенных сценариях.
Учитывая, что для крупномасштабной / высокой пропускной способности обработки асинхронных вызовов среднего уровня - единственный выход, NOCOUNT в значительной степени является обязательным требованием.