Groot SQL-resultaat over VPN: waar de rijen wachten

Query’s kunnen in milliseconden klaar zijn en er toch minuten over doen om een laptop via een VPN te bereiken. De server schrijft rijen in buffers, de verbinding vervoert ze en de client consumeert ze, en die fasen overlappen elkaar in plaats van elkaar op te volgen. Elk ervan kan de limiet worden. Zoek de fase die werkelijk wacht voordat u bandbreedte wijzigt of compressie inschakelt.

Drie fasen, één stopwatch

Splits de timer in twee getallen met verschillende betekenis: het moment waarop de eerste rij beschikbaar is en het moment waarop de laatste rij is geconsumeerd. Een raster dat de eerste pagina tekent, bewijst alleen dat de query is begonnen. De tijd van het volledige resultaat is wat de gebruiker ervaart bij het exporteren of scrollen naar het einde.

Noteer beide getallen met de querytekst, parameters en verbindingsinstellingen. Zonder die context is de vergelijking tussen twee verschillende taken, niet tussen twee locaties.

Lees het wachten vóór het netwerk

SQL Server schrijft resultaatrijen in uitvoerbuffers die de client ophaalt, en een client die langzaam consumeert kan de server op die verzending laten wachten. Het wachttype is ASYNC_NETWORK_IO, en Microsofts notitie voor probleemoplossing noemt grote resultaten en verwerking aan de clientzijde onder de oorzaken. Het wachten zegt dat het verzendpad geblokkeerd is, niet waarom.

Een langzame VPN kan bijdragen, maar ook een client die elke rij opmaakt, naar een bestand schrijft of pauzes neemt tussen batches. De naam van het wachten is een aanwijzing voor de volgende meting, geen oordeel over de verbinding.

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

Lees de teller terwijl de begrensde werkbelasting loopt, niet na een leeg uur, omdat cumulatieve tellers elke sessie sinds de start van het exemplaar mengen. Vergelijk het delta over de run in plaats van het totaal over de levensduur. Een groeiend delta tijdens de overdracht vernauwt de vraag tot verbruik of levering.

Zet beide clients op dezelfde klok

Voer een begrensde werkbelasting uit vanaf een client dicht bij de database en vanaf de externe client. Houd query, parameters, resultaatgrootte en verbindingsinstellingen identiek. Gebruik dezelfde meting aan beide kanten, want de uitvoeringstijd van de server, de weergavetijd van het raster en de exporttijd zijn drie verschillende klokken. Een getal aan de serverzijde vergelijken met een exporttimer aan de clientzijde levert een conclusie op die niet kan worden getest.

Als het pad verantwoordelijk lijkt, laat de netwerkeigenaar dan verlies, hertransmissies en behaalde doorvoer voor die specifieke stroom volgen terwijl de overdracht loopt. Een algemene snelheidstest kan een andere route, eindpunt of gelijktijdigheidspatroon gebruiken. Een klein succesvol verzoek zegt weinig over een langdurige resultaatoverdracht.

Snijd bytes weg voordat u het pad de schuld geeft

Filteren, aggregeren en alleen de benodigde kolommen selecteren verminderen zowel het overdrachtsvolume als het werk dat de client per rij doet. Behoud het bedoelde resultaat, want een rapport kan detail nodig hebben dat een samenvatting op het scherm niet heeft.

Voor herhaalbare exports kan een goedgekeurde uitvoeringslocatie dicht bij de database een gedefinieerde uitvoer schrijven die vervolgens één keer wordt geleverd. Dat verandert de werkstroom en de toegangscontroles ervan, en het is geen toestemming om een onbeperkte dump op een gedeelde host achter te laten.

Compressie is niet de standaardreparatie. Ondersteuning en beveiliging hangen af van het werkelijke protocol en de implementatie, en een gecomprimeerde stroom die de client langzaam decomprimeert kan de ervaring verslechteren. Meet eerst de fase en kies dan een ondersteunde wijziging voor die fase.