Czy typ oczekiwania ASYNC_NETWORK_IO nie ma się czym martwić?

Patrząc na listę procedur przechowywanych, których wykonanie zajmuje dużo czasu, wyróżnia się jako powodująca najwięcej oczekiwania. Jednak większość tego oczekiwania (81%) to ASYNC_NETWORK_IO i wiem dlaczego: procedura przechowywana przesyła około 400 MB informacji.

W dokumentacji stwierdza, że przyczyną ASYNC_NETWORK_IO jest to, że klient nie jest w stanie nadążyć za zalewem danych i to prawdopodobnie prawda. Nie jestem pewien, jak sprawić, by klient nadążył, ponieważ wystarczy wywołać procedurę przechowywaną za pośrednictwem ADO.NET, a następnie po prostu przetwarza zestaw danych.

Biorąc pod uwagę te informacje, czy powinienem martwić się typem oczekiwania ASYNC_NETWORK_IO na tę procedurę? Czy to rzeczywiście wpływa na wydajność serwera?

Dodatkowe informacje:

Korzystam z dodatku Service Pack 2 dla programu SQL Server 2005.
Aplikacja kliencka znajduje się w tym samym pudełku co SQL Server (wiem, wiem ... ale nic nie mogę na to poradzić).

— AngryHacker
źródło

Najlepszym sposobem na zastanowienie się nad tym rodzajem oczekiwania jest to, że w zapytaniu nic nie powoduje - zwraca dane do klienta. Zobaczysz również, że wielu z was ma połączone tabele w Access. Jedną z możliwości w zależności od aplikacji klienckiej jest podzielenie danych na mniejsze części lub po prostu zwrócenie mniejszej ilości danych. Jeśli nie jest to opcja, prawdopodobnie ograniczysz jej możliwości.

— JNK

Czy aplikacja kliencka łączy się przy użyciu pamięci współdzielonej lub TCP / IP? Czy aplikacja kliencka i SQL Server współużytkują ten sam zestaw rdzeni procesora, czy używasz techniki maskowania powinowactwa, aby je rozdzielić?

— Jon Seigel

Jest to domyślny typ połączenia - nic specjalnego - więc korzysta z pamięci współdzielonej. Obie aplikacje używają tego samego zestawu rdzeni - nie ma koligacji.

— AngryHacker

Czy Twoja pamięć SAN jest lokalna?

— Eric Higgins

@EricHiggins Tylko lokalny zestaw dysków twardych RAIDed.

— AngryHacker

Jak powiedziałeś, ten typ oczekiwania wskazuje, że aplikacja nie nadąża za programem SQL Server. To tak naprawdę oznacza, że SQL Server nie może wysyłać danych przez sieć tak szybko, jak by chciał.

Mogą być dwie podstawowe przyczyny:

Aplikacja jest napisana nieefektywnie i nie przetwarza wierszy wystarczająco szybko.
Sieć jest maksymalnie rozwinięta.

Jeśli sama aplikacja jest zbyt wolna, nie będzie znacznego wpływu na wydajność innych zapytań lub nie będzie jej wcale. Jeśli z drugiej strony potok jest zbyt mały, inne zapytania również nie mogą wysłać swoich wyników i muszą poczekać.

W tym drugim przypadku wszystkie połączenia czekałyby na ASYNC_NETWORK_IO. Powinieneś być w stanie wyraźnie zobaczyć ten wpływ.

— Sebastian Meine
źródło

W przypadku punktu 1. Pobieranie danych odbywa się za pośrednictwem ADO.NET przy użyciu standardowego kodu: var dataSet = new DataSet(); var da = new SqlDataAdapter(command); da.Fill(dataSet); Nie jestem więc pewien, co dokładnie może być wolne.

— AngryHacker

W przypadku punktu 2 aplikacja znajduje się w tym samym polu co SQL, a połączenie odbywa się za pomocą metody pamięci współużytkowanej. Teoretycznie powinno to być super szybkie.

— AngryHacker