Velký výsledek SQL přes VPN: kde řádky čekají

Dotazy mohou skončit v milisekundách a přesto trvat minuty, než dorazí přes VPN do notebooku. Server zapisuje řádky do bufferů, spojení je přenáší a klient je spotřebovává, a tyto fáze se překrývají, místo aby běžely postupně. Kterákoli z nich se může stát limitem. Najděte fázi, která skutečně čeká, dřív než změníte šířku pásma nebo zapnete kompresi.

Tři fáze, jedny stopky

Rozdělte časovač na dvě čísla s různým významem: okamžik, kdy je k dispozici první řádek, a okamžik, kdy je spotřebován poslední řádek. Mřížka, která vykreslí první stránku, dokazuje jen to, že dotaz začal. Doba úplného výsledku je to, co uživatel zažívá při exportu nebo posunu na konec.

Zapište obě čísla spolu s textem dotazu, parametry a nastavením připojení. Bez tohoto kontextu je srovnání mezi dvěma různými úlohami, ne mezi dvěma místy.

Přečtěte čekání dřív než síť

SQL Server zapisuje řádky výsledku do výstupních bufferů, odkud je klient načítá, a klient, který spotřebovává pomalu, může přimět server čekat na toto odeslání. Typ čekání je ASYNC_NETWORK_IO a poznámka Microsoftu k řešení potíží uvádí mezi příčinami velké výsledky a zpracování na straně klienta. Čekání říká, že cesta odeslání je zablokovaná, ne proč.

Pomalá VPN může přispět, ale stejně tak klient, který formátuje každý řádek, zapisuje do souboru nebo dělá pauzy mezi dávkami. Název čekání je ukazatel k dalšímu měření, ne verdikt o spojení.

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

Čtěte čítač, dokud běží omezená zátěž, ne po prázdné hodině, protože kumulativní čítače míchají každou relaci od spuštění instance. Porovnávejte rozdíl během běhu, ne celkový součet za dobu života. Rostoucí rozdíl během přenosu zužuje otázku na spotřebu nebo doručení.

Postavte oba klienty na stejné hodiny

Spusťte omezenou zátěž z klienta blízko databáze a ze vzdáleného klienta. Dotaz, parametry, velikost výsledku a nastavení připojení držte totožné. Použijte stejné měření na obou stranách, protože doba provádění na serveru, doba zobrazení mřížky a doba exportu jsou troje různé hodiny. Porovnání čísla ze strany serveru s exportním časovačem na straně klienta dává závěr, který nelze ověřit.

Když se cesta zdá být viníkem, nechte správce sítě sledovat ztráty, opakované přenosy a dosaženou propustnost pro tento konkrétní tok, dokud přenos běží. Obecný test rychlosti může použít jinou trasu, koncový bod nebo vzorec souběžnosti. Malý úspěšný požadavek málo vypovídá o trvajícím přenosu výsledku.

Uberte bajty, než obviníte cestu

Filtrování, agregace a výběr jen potřebných sloupců snižují objem přenosu i práci, kterou klient s každým řádkem dělá. Zachovejte zamýšlený výsledek, protože sestava může potřebovat detail, který souhrn na obrazovce nemá.

Pro opakovatelné exporty může schválené místo spuštění blízko databáze zapsat definovaný výstup, který se pak doručí jednou. To mění pracovní postup a jeho řízení přístupu a není to svolení nechat neomezený výpis na sdíleném hostiteli.

Komprese není výchozí oprava. Podpora a bezpečnost závisí na skutečném protokolu a nasazení a komprimovaný proud, který klient pomalu rozbaluje, může zážitek zhoršit. Nejprve změřte fázi, pak zvolte podporovanou změnu pro tuto fázi.