Stort SQL-resultat over VPN: kvar radene ventar

Spørjingar kan bli ferdige på millisekund og likevel bruke minutt på å nå ein berbar PC over ein VPN. Tenaren skriv rader i bufferar, sambandet fraktar dei, og klienten brukar dei, og desse trinna overlappar i staden for å køyre etter kvarandre. Kva som helst av dei kan bli grensa. Finn trinnet som faktisk ventar, før du endrar bandbreidd eller slår på komprimering.

Tre trinn, éi stoppeklokke

Del timeren i to tal med ulik tyding: augneblinken då den første rada er tilgjengeleg, og augneblinken då den siste rada er brukt. Eit rutenett som teiknar den første sida, beviser berre at spørjinga starta. Tida for heile resultatet er det brukaren opplever når dei eksporterer eller rullar til slutten.

Noter båe tala saman med spørjingsteksten, parametrane og tilkoplingsinnstillingane. Utan den konteksten er samanlikninga mellom to ulike jobbar, ikkje to stader.

Les ventinga før nettverket

SQL Server skriv resultatrader i utdatabufferar som klienten hentar, og ein klient som brukar sakte, kan få tenaren til å vente på den sendinga. Ventetypen er ASYNC_NETWORK_IO, og Microsofts feilsøkingsnotat nemner store resultat og handsaming på klientsida mellom årsakene. Ventinga seier at sendebanen er blokkert, ikkje kvifor.

Ein langsam VPN kan bidra, men det kan òg ein klient som formaterer kvar rad, skriv til ei fil eller tek pausar mellom batchar. Namnet på ventinga er ein peikar til neste måling, ikkje ein dom over sambandet.

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

Les teljaren medan den avgrensa arbeidsmengda køyrer, ikkje etter ein ledig time, fordi kumulative teljarar blandar kvar økt sidan førekomsten starta. Samanlikn deltaet over køyringa i staden for livstidstalet. Eit veksande delta under overføringa snevrar spørsmålet inn til forbruk eller levering.

Set båe klientane på same klokka

Køyr ei avgrensa arbeidsmengd frå ein klient nær databasen og frå den eksterne klienten. Hald spørjing, parametrar, resultatstorleik og tilkoplingsinnstillingar identiske. Bruk same måling på båe sider, fordi køyretida til tenaren, rutenettvisningstida og eksporttida er tre ulike klokker. Å samanlikne eit tal frå tenarsida med ein eksporttimer på klientsida gjev ein konklusjon som ikkje kan testast.

Når vegen ser ansvarleg ut, la nettverkseigaren overvake tap, omsendingar og oppnådd gjennomstrøyming for nettopp den straumen medan overføringa går. Ein generisk hastetest kan bruke ei anna rute, endepunkt eller samtidigheitsmønster. Ein liten vellukka førespurnad seier lite om ein vedvarande resultatoverføring.

Kutt byte før du klandrar vegen

Filtrering, aggregering og val av berre dei nødvendige kolonnane reduserer både overføringsvolumet og arbeidet klienten gjer med kvar rad. Ta vare på det tiltenkte resultatet, fordi ein rapport kan trengje detaljar som eit samandrag på skjermen ikkje har.

For gjentekne eksportar kan ein godkjend køyrestad nær databasen skrive ein definert utdata som deretter blir levert éin gong. Det endrar arbeidsflyten og tilgangskontrollane, og det er ikkje løyve til å leggje att ein ubegrensa dump på ein delt vert.

Komprimering er ikkje standardreparasjonen. Støtte og tryggleik avheng av den faktiske protokollen og distribusjonen, og ein komprimert straum som klienten pakkar ut sakte, kan gjere opplevinga verre. Mål trinnet først, og vel deretter ei støtta endring for det trinnet.