Stort SQL-resultat over VPN: hvor rækkerne venter

Forespørgsler kan være færdige på millisekunder og alligevel tage minutter om at nå en bærbar computer over en VPN. Serveren skriver rækker i buffere, forbindelsen transporterer dem, og klienten forbruger dem, og disse trin overlapper i stedet for at køre efter hinanden. Ethvert af dem kan blive grænsen. Find det trin, der faktisk venter, før du ændrer båndbredde eller slår komprimering til.

Tre trin, ét stopur

Del timeren op i to tal med forskellig betydning: det øjeblik, hvor den første række er tilgængelig, og det øjeblik, hvor den sidste række er forbrugt. Et grid, der tegner den første side, beviser kun, at forespørgslen er startet. Tiden for hele resultatet er det, brugeren oplever, når de eksporterer eller ruller til slutningen.

Noter begge tal sammen med forespørgselsteksten, parametrene og forbindelsesindstillingerne. Uden den kontekst er sammenligningen mellem to forskellige opgaver, ikke to placeringer.

Læs ventetiden før netværket

SQL Server skriver resultatrækker i outputbuffere, som klienten henter, og en klient, der forbruger langsomt, kan få serveren til at vente på den sending. Ventetypen er ASYNC_NETWORK_IO, og Microsofts fejlfindingsnotat nævner store resultater og behandling på klientsiden blandt årsagerne. Ventetiden fortæller, at sendestien er blokeret, ikke hvorfor.

En langsom VPN kan bidrage, men det kan en klient også, der formaterer hver række, skriver til en fil eller holder pauser mellem batches. Ventetidens navn er en pegepind til den næste 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';

Læs tælleren, mens den afgrænsede arbejdsbyrde kører, ikke efter en ledig time, fordi kumulative tællere blander hver session siden instansen startede. Sammenlign deltaet over kørslen i stedet for levetidstallet. Et voksende delta under overførslen indsnævrer spørgsmålet til forbrug eller levering.

Sæt begge klienter på samme ur

Kør en afgrænset arbejdsbyrde fra en klient tæt på databasen og fra den eksterne klient. Hold forespørgsel, parametre, resultatstørrelse og forbindelsesindstillinger identiske. Brug samme måling på begge sider, fordi serverens udførelsestid, gridvisningstid og eksporttid er tre forskellige ure. At sammenligne et tal fra serversiden med en eksporttimer på klientsiden giver en konklusion, der ikke kan testes.

Når stien ser ansvarlig ud, skal netværksejeren overvåge tab, gensendinger og opnået gennemstrømning for netop den strøm, mens overførslen kører. En generisk hastighedstest kan bruge en anden rute, slutpunkt eller samtidighedsmønster. En lille vellykket anmodning siger lidt om en vedvarende resultatoverførsel.

Skær bytes før du bebrejder stien

Filtrering, aggregering og valg af kun de nødvendige kolonner reducerer både overførselsvolumen og det arbejde, klienten udfører med hver række. Bevar det tilsigtede resultat, fordi en rapport kan have brug for detaljer, som et resumé på skærmen ikke har.

Til gentagne eksporter kan et godkendt udførelsessted tæt på databasen skrive et defineret output, som derefter leveres én gang. Det ændrer arbejdsgangen og dens adgangskontroller, og det er ikke tilladelse til at efterlade en ubegrænset dump på en delt vært.

Komprimering er ikke den standardmæssige reparation. Support og sikkerhed afhænger af den faktiske protokol og udrulning, og en komprimeret strøm, som klienten udpakker langsomt, kan gøre oplevelsen værre. Mål først trinnet, og vælg derefter en understøttet ændring for det trin.