Veľký výsledok SQL cez VPN: kde čakajú riadky

Dopyty môžu skončiť za milisekundy a napriek tomu trvať minúty, kým sa cez VPN dostanú do notebooku. Server zapisuje riadky do bufferov, spojenie ich prenáša a klient ich spotrebúva, a tieto fázy sa prekrývajú, namiesto toho aby išli postupne. Ktorákoľvek z nich sa môže stať limitom. Nájdite fázu, ktorá skutočne čaká, skôr než zmeníte šírku pásma alebo zapnete kompresiu.

Tri fázy, jedny stopky

Rozdeľte časovač na dve čísla s rôznym významom: okamih, keď je k dispozícii prvý riadok, a okamih, keď bol spotrebovaný posledný riadok. Mriežka, ktorá vykreslí prvú stránku, dokazuje len to, že dopyt začal. Čas úplného výsledku je to, čo používateľ zažíva pri exporte alebo posúvaní na koniec.

Zapíšte obe čísla spolu s textom dopytu, parametrami a nastaveniami pripojenia. Bez tohto kontextu je porovnanie medzi dvoma rôznymi úlohami, nie medzi dvoma miestami.

Prečítajte čakanie pred sieťou

SQL Server zapisuje riadky výsledku do výstupných bufferov, odkiaľ ich klient načítava, a pomaly spotrebúvajúci klient môže prinútiť server čakať na toto odoslanie. Typ čakania je ASYNC_NETWORK_IO a poznámka Microsoftu na riešenie problémov uvádza medzi príčinami veľké výsledky a spracovanie na strane klienta. Čakanie hovorí, že cesta odoslania je zablokovaná, nie prečo.

Pomalá VPN môže prispieť, ale rovnako aj klient, ktorý formátuje každý riadok, zapisuje do súboru alebo robí pauzy medzi dávkami. Názov čakania je ukazovateľ na ďalšie meranie, nie verdikt o spojení.

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

Čítajte počítadlo, kým beží obmedzená záťaž, nie po prázdnej hodine, pretože kumulatívne počítadlá miešajú každú reláciu od spustenia inštancie. Porovnávajte rozdiel počas behu, nie celkový súčet za celý život. Rastúci rozdiel počas prenosu zužuje otázku na spotrebu alebo doručenie.

Postavte oboch klientov na rovnaké hodiny

Spustite obmedzenú záťaž z klienta blízko databázy a zo vzdialeného klienta. Dopyt, parametre, veľkosť výsledku a nastavenia pripojenia držte identické. Použite rovnaké meranie na oboch stranách, pretože čas vykonania servera, čas zobrazenia mriežky a čas exportu sú troje rôzne hodiny. Porovnanie čísla zo strany servera s exportným časovačom na strane klienta dáva záver, ktorý nemožno overiť.

Keď sa cesta zdá byť zodpovedná, nechajte správcu siete sledovať straty, opakované prenosy a dosiahnutú priepustnosť pre tento konkrétny tok, kým prenos beží. Všeobecný test rýchlosti môže použiť inú trasu, koncový bod alebo vzor súbežnosti. Malá úspešná požiadavka málo hovorí o trvalom prenose výsledku.

Uberte bajty, skôr než obviníte cestu

Filtrovanie, agregácia a výber iba potrebných stĺpcov znižujú objem prenosu aj prácu, ktorú klient robí s každým riadkom. Zachovajte zamýšľaný výsledok, pretože zostava môže potrebovať detail, ktorý súhrn na obrazovke nemá.

Pre opakovateľné exporty môže schválené miesto spustenia blízko databázy zapísať definovaný výstup, ktorý sa potom doručí raz. To mení pracovný postup a jeho riadenie prístupu a nie je to povolenie nechať neobmedzený výpis na zdieľanom hostiteľovi.

Kompresia nie je predvolená oprava. Podpora a bezpečnosť závisia od skutočného protokolu a nasadenia a komprimovaný prúd, ktorý klient pomaly rozbaľuje, môže zážitok zhoršiť. Najprv zmerajte fázu, potom zvoľte podporovanú zmenu pre túto fázu.