Duży wynik SQL przez VPN: gdzie czekają wiersze

Zapytania mogą kończyć się w milisekundach, a mimo to docierać do laptopa przez VPN minutami. Serwer zapisuje wiersze w buforach, połączenie je przenosi, a klient je konsumuje, i te etapy nakładają się na siebie, zamiast przebiegać kolejno. Każdy z nich może stać się ograniczeniem. Znajdź etap, który naprawdę czeka, zanim zmienisz przepustowość lub włączysz kompresję.

Trzy etapy, jeden stoper

Podziel stoper na dwie liczby o różnym znaczeniu: moment, w którym pierwszy wiersz jest dostępny, i moment, w którym ostatni wiersz został skonsumowany. Siatka, która rysuje pierwszą stronę, dowodzi tylko, że zapytanie się zaczęło. Czas pełnego wyniku to to, czego użytkownik doświadcza podczas eksportu lub przewijania do końca.

Zapisz obie liczby wraz z tekstem zapytania, parametrami i ustawieniami połączenia. Bez tego kontekstu porównanie dotyczy dwóch różnych zadań, a nie dwóch lokalizacji.

Odczytaj czekanie przed siecią

SQL Server zapisuje wiersze wyniku do buforów wyjściowych, aby klient je pobrał, a klient, który konsumuje wolno, może zmusić serwer do czekania na to wysłanie. Typ czekania to ASYNC_NETWORK_IO, a nota firmy Microsoft o rozwiązywaniu problemów wymienia duże wyniki i przetwarzanie po stronie klienta wśród przyczyn. Czekanie mówi, że ścieżka wysyłania jest zablokowana, a nie dlaczego.

Wolny VPN może się do tego przyczyniać, ale także klient, który formatuje każdy wiersz, zapisuje do pliku lub robi pauzy między partiami. Nazwa czekania jest wskazówką do następnego pomiaru, a nie wyrokiem o łączu.

SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';

Czytaj licznik, gdy działa ograniczone obciążenie, a nie po pustej godzinie, ponieważ liczniki narastające mieszają każdą sesję od uruchomienia instancji. Porównuj różnicę w trakcie przebiegu, a nie sumę z całego życia. Rosnąca różnica podczas transferu zawęża pytanie do konsumpcji lub dostarczenia.

Postaw oba klienty na tym samym zegarze

Uruchom ograniczone obciążenie z klienta blisko bazy danych i ze zdalnego klienta. Utrzymaj identyczne zapytanie, parametry, rozmiar wyniku i ustawienia połączenia. Użyj tego samego pomiaru po obu stronach, ponieważ czas wykonania serwera, czas wyświetlania siatki i czas eksportu to trzy różne zegary. Porównanie liczby po stronie serwera z czasomierzem eksportu po stronie klienta daje wniosek, którego nie można sprawdzić.

Gdy ścieżka wydaje się odpowiedzialna, poproś właściciela sieci o obserwację utraty pakietów, retransmisji i osiągniętej przepustowości dla tego konkretnego strumienia podczas transferu. Ogólny test szybkości może używać innej trasy, punktu końcowego lub wzorca współbieżności. Małe udane żądanie niewiele mówi o długotrwałym transferze wyniku.

Odetnij bajty, zanim obwinisz ścieżkę

Filtrowanie, agregacja i wybór tylko potrzebnych kolumn zmniejszają zarówno wolumen transferu, jak i pracę, którą klient wykonuje przy każdym wierszu. Zachowaj zamierzony wynik, ponieważ raport może potrzebować szczegółu, którego nie ma podsumowanie na ekranie.

W przypadku powtarzalnych eksportów zatwierdzona lokalizacja wykonania blisko bazy danych może zapisać zdefiniowany wynik, który następnie jest dostarczany raz. To zmienia przepływ pracy i jego kontrolę dostępu i nie jest zgodą na pozostawienie nieograniczonego zrzutu na współdzielonym hoście.

Kompresja nie jest domyślną naprawą. Wsparcie i bezpieczeństwo zależą od rzeczywistego protokołu i wdrożenia, a skompresowany strumień, który klient wolno dekompresuje, może pogorszyć doświadczenie. Najpierw zmierz etap, a potem wybierz obsługiwaną zmianę dla tego etapu.