Stort SQL-resultat over VPN: hvor radene venter

Spørringer kan bli ferdige på millisekunder og likevel bruke minutter på å nå en bærbar PC over en VPN. Serveren skriver rader i buffere, forbindelsen frakter dem, og klienten bruker dem, og disse trinnene overlapper i stedet for å kjøre etter hverandre. Ethvert av dem kan bli grensen. Finn trinnet som faktisk venter, før du endrer båndbredde eller slår på komprimering.

Tre trinn, én stoppeklokke

Del timeren i to tall med forskjellig betydning: øyeblikket da den første raden er tilgjengelig, og øyeblikket da den siste raden er brukt. Et rutenett som tegner den første siden, beviser bare at spørringen startet. Tiden for hele resultatet er det brukeren opplever når de eksporterer eller ruller til slutten.

Noter begge tallene sammen med spørringsteksten, parameterne og tilkoblingsinnstillingene. Uten den konteksten er sammenligningen mellom to forskjellige jobber, ikke to steder.

Les ventingen før nettverket

SQL Server skriver resultatrader i utdatabuffere som klienten henter, og en klient som bruker sakte, kan få serveren til å vente på den sendingen. Ventetypen er ASYNC_NETWORK_IO, og Microsofts feilsøkingsnotat nevner store resultater og behandling på klientsiden blant årsakene. Ventingen sier at sendebanen er blokkert, ikke hvorfor.

En langsom VPN kan bidra, men det kan også en klient som formaterer hver rad, skriver til en fil eller tar pauser mellom batcher. Navnet på ventingen er en peker til neste måling, ikke en dom over forbindelsen.

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

Les telleren mens den avgrensede arbeidsmengden kjører, ikke etter en ledig time, fordi kumulative tellere blander hver økt siden forekomsten startet. Sammenlign deltaet over kjøringen i stedet for livstidstallet. Et voksende delta under overføringen snevrer spørsmålet inn til forbruk eller levering.

Sett begge klientene på samme klokke

Kjør en avgrenset arbeidsmengde fra en klient nær databasen og fra den eksterne klienten. Hold spørring, parametere, resultatstørrelse og tilkoblingsinnstillinger identiske. Bruk samme måling på begge sider, fordi serverens kjøretid, rutenettvisningstid og eksporttid er tre forskjellige klokker. Å sammenligne et tall fra serversiden med en eksporttimer på klientsiden gir en konklusjon som ikke kan testes.

Når veien ser ansvarlig ut, la nettverkseieren overvåke tap, omsendinger og oppnådd gjennomstrømning for nettopp den strømmen mens overføringen pågår. En generisk hastighetstest kan bruke en annen rute, endepunkt eller samtidighetsmønster. En liten vellykket forespørsel sier lite om en vedvarende resultatoverføring.

Kutt bytes før du klandrer veien

Filtrering, aggregering og valg av bare de nødvendige kolonnene reduserer både overføringsvolumet og arbeidet klienten gjør med hver rad. Behold det tiltenkte resultatet, fordi en rapport kan trenge detaljer som et sammendrag på skjermen ikke har.

For gjentatte eksporter kan et godkjent kjørested nær databasen skrive en definert utdata som deretter leveres én gang. Det endrer arbeidsflyten og tilgangskontrollene, og det er ikke tillatelse til å legge igjen en ubegrenset dump på en delt vert.

Komprimering er ikke standardreparasjonen. Støtte og sikkerhet avhenger av den faktiske protokollen og distribusjonen, og en komprimert strøm som klienten pakker ut sakte, kan gjøre opplevelsen verre. Mål trinnet først, og velg deretter en støttet endring for det trinnet.