Groot SQL-resultaat oor VPN: waar die rye wag
’n Groot SQL-resultaat wag op drie plekke: bedienerbuffers, die VPN-pad en die kliënt. Meet elke fase voordat jy bandwydte verander of kompressie aanskakel.
Navrae kan in millisekondes klaarkry en steeds minute neem om ’n skootrekenaar oor ’n VPN te bereik. Die bediener skryf rye in buffers, die verbinding dra dit, en die kliënt verbruik dit, en dié fases oorvleuel eerder as om in volgorde te loop. Enigeen van hulle kan die beperking word. Vind die fase wat werklik wag voordat jy bandwydte verander of kompressie aanskakel.
Drie fases, een stophorlosie
Verdeel die tydhouer in twee getalle met verskillende betekenisse: die oomblik wanneer die eerste ry beskikbaar is en die oomblik wanneer die laaste ry verbruik is. ’n Rooster wat die eerste bladsy teken, bewys net dat die navraag begin het. Die volle-resultaattyd is wat die gebruiker ervaar wanneer hulle uitvoer of tot onder rol.
Teken albei getalle op saam met die navraagteks, parameters en verbindingsinstellings. Sonder daardie konteks is die vergelyking tussen twee verskillende take, nie twee liggings nie.
Lees die wag voor die netwerk
SQL Server skryf resultaatrye in uitsetbuffers vir die kliënt om te haal, en ’n kliënt wat stadig verbruik kan die bediener laat wag op daardie stuur. Die wagtipe is ASYNC_NETWORK_IO, en Microsoft se probleemoplossingsnota noem groot resultate en kliëntkant-verwerking onder die oorsake. Die wag sê vir jou dat die stuurpad geblokkeer is, nie hoekom nie.
’n Stadige VPN kan bydra, maar so ook ’n kliënt wat elke ry formatteer, na ’n lêer skryf of tussen bondels pouses maak. Die wagnaam is ’n wyser na die volgende meting, nie ’n uitspraak oor die skakel nie.
SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'ASYNC_NETWORK_IO';
Lees die teller terwyl die begrensde werklaas loop, nie na ’n ledige uur nie, want kumulatiewe tellers meng elke sessie sedert die instansie begin het. Vergelyk die delta oor die loop eerder as die leeftydtotaal. ’n Groeiende delta tydens die oordrag vernou die vraag na verbruik of aflewering.
Sit albei kliënte op dieselfde klok
Laat ’n begrensde werklaas loop van ’n kliënt naby die databasis en van die afgeleë kliënt. Hou navraag, parameters, resultaatgrootte en verbindingsinstellings identies. Gebruik dieselfde meting aan albei kante, want bedieneruitvoertyd, roostervetraagtyd en uitvoertyd is drie verskillende klokke. Om ’n bedienerkant-getal met ’n kliëntkant-uitvoertydhouer te vergelyk, lewer ’n gevolgtrekking wat nie getoets kan word nie.
Wanneer die pad verantwoordelik lyk, laat die netwerkeienaar verlies, herversendings en behaalde deurvoer vir daardie spesifieke vloei dophou terwyl die oordrag loop. ’n Algemene spoedtoets mag ’n ander roete, eindpunt of gelyktydigheidpatroon gebruik. ’n Klein suksesvolle versoek sê min oor ’n volgehoue resultaat-oordrag.
Sny grepe voordat jy die pad blameer
Filtering, samevoeging en die keuse van net die nodige kolomme verminder beide die oordragvolume en die werk wat die kliënt met elke ry doen. Bewaar die bedoelde resultaat, want ’n verslag mag besonderhede nodig hê wat ’n samevatting op die skerm nie het nie.
Vir herhaalbare uitvoere kan ’n goedgekeurde uitvoeringsplek naby die databasis ’n gedefinieerde uitset skryf wat dan een keer afgelewer word. Dit verander die werkvloei en sy toegangsbeheer, en dit is nie toestemming om ’n onbeperkte dump op ’n gedeelde gasheer te laat nie.
Kompressie is nie die standaard herstel nie. Ondersteuning en sekuriteit hang van die werklike protokol en ontplooiing af, en ’n gekompakte stroom wat die kliënt stadig dekomprimeer kan die ervaring vererger. Meet eers die fase en kies dan ’n ondersteunde verandering vir daardie fase.