Istnieją scenariusze, w których opcja SET NOCOUNT ON jest obowiązkowa. Podczas projektowania warstwy środkowej o wysokiej wydajności opartej na przetwarzaniu asynchronicznym wykorzystującym pulę wątków za pomocą metod BeginExecuteXXX programu SqlClient, występuje bardzo poważny problem z liczbą wierszy. Metody BeginExecute kończą się zaraz po pierwszym pakiet odpowiedzi jest zwracany przez serwer. Ale kiedy wywoływane jest EndExecuteXXX, kończy się to na żądaniach innych niż zapytania po zakończeniu połączenia. Każda odpowiedź licznika wierszy jest odpowiedzią. Podczas przetwarzania nawet umiarkowanie skomplikowanych procedur liczba pierwszych wierszy może powrócić w ciągu 5-10 ms, podczas gdy połączenie kończy się w ciągu 300-500 ms. Zamiast wywołania złożonego żądania asynchronicznego po 500ms, oddzwania po 5 ms, a następnie bloki wywołania zwrotnego w EndExecuteXXX przez 495 ms. W rezultacie wywołania asynchroniczne kończą się przedwcześnie i blokują wątek z puli wątków w wywołaniach EndExecuteNonQuery. Prowadzi to do zagłodzenia ThreadPool. Widziałem, jak systemy o wysokiej wydajności poprawiają przepustowość z setek połączeń na sekundę do tysięcy połączeń na sekundę po prostu przez dodanie opcji SET NOCOUNT ON w określonych sytuacjach.
Biorąc pod uwagę, że w przypadku przetwarzania na dużą skalę/wysokiej przepustowości wywołania asynchroniczne w warstwie pośredniej są jedyną drogą do przejścia, NOCOUNT jest prawie obowiązkowym wymaganiem.
