Liels SQL rezultāts caur VPN: kur rindas gaida

Vaicājumi var pabeigties milisekundēs un tomēr aizņemt minūtes, lai caur VPN sasniegtu klēpjdatoru. Serveris raksta rindas buferos, savienojums tās pārvieto, un klients tās patērē, un šie posmi pārklājas, nevis notiek secīgi. Jebkurš no tiem var kļūt par ierobežojumu. Atrodiet posmu, kas patiešām gaida, pirms maināt joslas platumu vai ieslēdzat saspiešanu.

Trīs posmi, viens hronometrs

Sadaliet taimeri divos dažādas nozīmes skaitļos: brīdī, kad pirmā rinda ir pieejama, un brīdī, kad pēdējā rinda ir patērēta. Režģis, kas uzzīmē pirmo lapu, pierāda tikai to, ka vaicājums ir sācies. Pilna rezultāta laiks ir tas, ko lietotājs piedzīvo, eksportējot vai ritinot līdz beigām.

Pierakstiet abus skaitļus kopā ar vaicājuma tekstu, parametriem un savienojuma iestatījumiem. Bez šī konteksta salīdzinājums ir starp diviem dažādiem darbiem, nevis divām vietām.

Nolasiet gaidīšanu pirms tīkla

SQL Server raksta rezultāta rindas izvades buferos, lai klients tās paņemtu, un lēni patērējošs klients var likt serverim gaidīt šo sūtīšanu. Gaidīšanas tips ir ASYNC_NETWORK_IO, un Microsoft problēmu novēršanas piezīmē starp cēloņiem min lielus rezultātus un apstrādi klienta pusē. Gaidīšana pasaka, ka sūtīšanas ceļš ir bloķēts, nevis kāpēc.

Lēns VPN var veicināt, bet arī klients, kas formatē katru rindu, raksta failā vai veic pauzes starp partijām. Gaidīšanas nosaukums ir rādītājs uz nākamo mērījumu, nevis spriedums par savienojumu.

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

Lasiet skaitītāju, kamēr darbojas ierobežotā slodze, nevis pēc tukšas stundas, jo uzkrājošie skaitītāji sajauc katru sesiju kopš instances palaišanas. Salīdziniet starpību visā palaišanas laikā, nevis mūža kopsummu. Pārsūtīšanas laikā pieaugošā starpība sašaurina jautājumu līdz patēriņam vai piegādei.

Novietojiet abus klientus uz viena pulksteņa

Palaidiet ierobežotu slodzi no klienta, kas atrodas tuvu datubāzei, un no attālā klienta. Saglabājiet vaicājumu, parametrus, rezultāta lielumu un savienojuma iestatījumus identiskus. Izmantojiet vienu un to pašu mērījumu abās pusēs, jo servera izpildes laiks, režģa attēlošanas laiks un eksportēšanas laiks ir trīs dažādi pulksteņi. Servera puses skaitļa salīdzināšana ar klienta puses eksportēšanas taimeri dod secinājumu, ko nevar pārbaudīt.

Kad ceļš šķiet atbildīgs, palūdziet tīkla īpašniekam uzraudzīt zudumus, atkārtotas pārsūtīšanas un sasniegto caurlaidspēju tieši šai plūsmai, kamēr notiek pārsūtīšana. Vispārīgs ātruma tests var izmantot citu maršrutu, galapunktu vai paralēlisma modeli. Neliels veiksmīgs pieprasījums maz pasaka par ilgstošu rezultāta pārsūtīšanu.

Samaziniet baitus, pirms vainojat ceļu

Filtrēšana, agregācija un tikai nepieciešamo kolonnu atlase samazina gan pārsūtīšanas apjomu, gan darbu, ko klients veic ar katru rindu. Saglabājiet paredzēto rezultātu, jo pārskatam var būt vajadzīga detaļa, kuras ekrānā redzamajā kopsavilkumā nav.

Atkārtojamiem eksportiem apstiprināta izpildes vieta datubāzes tuvumā var ierakstīt definētu izvadi, kas pēc tam tiek piegādāta vienreiz. Tas maina darbplūsmu un tās piekļuves kontroli, un tas nav atļauja atstāt neierobežotu izgāztuvi koplietotā resursdatorā.

Saspiešana nav noklusējuma labojums. Atbalsts un drošība ir atkarīgi no faktiskā protokola un izvietojuma, un saspiesta plūsma, ko klients lēni atspiež, var pasliktināt pieredzi. Vispirms izmēriet posmu, pēc tam izvēlieties atbalstītu izmaiņu šim posmam.