Stort SQL-resultat över VPN: var raderna väntar

Frågor kan bli klara på millisekunder och ändå ta minuter att nå en bärbar dator över en VPN. Servern skriver rader i buffertar, anslutningen transporterar dem och klienten konsumerar dem, och dessa steg överlappar varandra i stället för att köras i tur och ordning. Vilket som helst av dem kan bli gränsen. Hitta steget som faktiskt väntar innan du ändrar bandbredd eller slår på komprimering.

Tre steg, ett stoppur

Dela upp timern i två tal med olika betydelse: ögonblicket då den första raden är tillgänglig och ögonblicket då den sista raden har konsumerats. Ett rutnät som ritar den första sidan bevisar bara att frågan har startat. Tiden för hela resultatet är det användaren upplever när den exporterar eller rullar till slutet.

Anteckna båda talen tillsammans med frågetexten, parametrarna och anslutningsinställningarna. Utan den kontexten är jämförelsen mellan två olika jobb, inte två platser.

Läs väntan före nätverket

SQL Server skriver resultatrader i utdatabuffertar som klienten hämtar, och en klient som konsumerar långsamt kan få servern att vänta på den sändningen. Väntetypen är ASYNC_NETWORK_IO, och Microsofts felsökningsnot nämner stora resultat och bearbetning på klientsidan bland orsakerna. Väntan säger att sändningsvägen är blockerad, inte varför.

En långsam VPN kan bidra, men det kan också en klient som formaterar varje rad, skriver till en fil eller pausar mellan batchar. Namnet på väntan är en pekare till nästa mätning, inte en dom över anslutningen.

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

Läs räknaren medan den begränsade arbetsbelastningen körs, inte efter en ledig timme, eftersom kumulativa räknare blandar varje session sedan instansen startade. Jämför deltat under körningen i stället för livstidssumman. Ett växande delta under överföringen snävar in frågan till förbrukning eller leverans.

Sätt båda klienterna på samma klocka

Kör en begränsad arbetsbelastning från en klient nära databasen och från fjärrklienten. Håll fråga, parametrar, resultatstorlek och anslutningsinställningar identiska. Använd samma mätning på båda sidor, eftersom serverns körningstid, rutnätets visningstid och exporttiden är tre olika klockor. Att jämföra ett tal från serversidan med en exporttimer på klientsidan ger en slutsats som inte kan testas.

När vägen verkar ansvarig, låt nätverksägaren följa förluster, omsändningar och uppnådd genomströmning för just det flödet medan överföringen pågår. Ett allmänt hastighetstest kan använda en annan rutt, slutpunkt eller samtidighetsmodell. En liten lyckad begäran säger lite om en varaktig resultatöverföring.

Skär bort byte innan du skyller på vägen

Filtrering, aggregering och val av bara de nödvändiga kolumnerna minskar både överföringsvolymen och arbetet som klienten gör med varje rad. Bevara det avsedda resultatet, eftersom en rapport kan behöva detaljer som en sammanfattning på skärmen inte har.

För upprepbara exporter kan en godkänd körningsplats nära databasen skriva en definierad utdata som sedan levereras en gång. Det ändrar arbetsflödet och dess åtkomstkontroller, och det är inte tillstånd att lämna en obegränsad dump på en delad värd.

Komprimering är inte standardreparationen. Stöd och säkerhet beror på den faktiska protokollen och distributionen, och en komprimerad ström som klienten packar upp långsamt kan försämra upplevelsen. Mät steget först och välj sedan en stödd ändring för det steget.