Grut SQL-resultaat oer VPN: wêr’t de rigen wachtsje

Fragen kinne yn millisekonden klear wêze en dochs minuten nimme om in laptop oer in VPN te berikken. De tsjinner skriuwt rigen yn buffers, de ferbining ferfiert se, en de klant ferbrûkt se, en dy fazen oerlaapje elkoar ynstee fan sekuer te rinnen. Elk fan harren kin de limyt wurde. Fyn de faze dy’t wier wachtet foardat jo bânbreedte feroarje of kompresje oansette.

Trije fazen, ien stopwatch

Diel de timer yn twa getallen mei ferskillende betsjutting: it momint dat de earste rige beskikber is en it momint dat de lêste rige ferbrûkt is. In raster dat de earste side skildert, bewiist allinnich dat de fraach begûn is. De tiid fan it folsleine resultaat is wat de brûker belibbet as er eksportearret of nei it ein skoot.

Skriuw beide getallen op mei de fraachtekst, parameters en ferbiningsynstellingen. Sûnder dy kontekst is de ferliking tusken twa ferskillende taken, net tusken twa lokaasjes.

Lês it wachtsjen foar it netwurk

SQL Server skriuwt resultaatrigen yn útfierbuffers foar de klant om op te heljen, en in klant dy’t stadich ferbrûkt, kin de tsjinner op dy ferstjoering wachtsje litte. It wachttetype is ASYNC_NETWORK_IO, en Microsoft syn notysje foar it oplossen fan problemen neamt grutte resultaten en ferwurking oan klantkant ûnder de oarsaken. It wachtsjen fertelt dat it ferstjoerpaad blokkearre is, net wêrom.

In stadige VPN kin bydrage, mar ek in klant dy’t elke rige opmaakt, nei in bestân skriuwt of tusken batches stopt. De namme fan it wachtsjen is in wiizer nei de folgjende mjitting, gjin oardiel oer de ferbining.

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

Lês de teller wylst de beheinde wurklêst rint, net nei in idle oere, want kumulative tellers minge elke sesje sûnt de start fan ’e ynstânsje. Ferlykje de delta oer de útfier ynstee fan it libbenslangtotaal. In groeiende delta by de oerdracht ferneaut de fraach nei ferbrûk of levering.

Set beide klanten op deselde klok

Lit in beheinde wurklêst rinne fan in klant tichtby de databank en fan ’e fiere klant. Hâld fraach, parameters, resultaatgrutte en ferbiningsynstellingen identyk. Brûk deselde mjitting oan beide kanten, want tsjinner-útfiertiid, rasterwerjeftertiid en eksporttiid binne trije ferskillende klokken. In tsjinnerkant-getal fergelykje mei in klantkant-eksporttimer jout in konklúzje dy’t net te testen is.

As it paad ferantwurdlik liket, lit de netwurkeigner dan ferlies, werstjoeringen en berikte trochset foar dy spesifike stream besjen wylst de oerdracht rint. In algemiene snelheidstest kin in oare rûte, einpunt of parallelpatroan brûke. In lyts suksesfol fersyk seit net folle oer in oanhâldende resultaat-oerdracht.

Snij bytes foardat jo it paad beskuldigje

Filterjen, aggregearjen en it kiezen fan allinnich de nedige kolommen ferminderje sawol it oerdrachtsfolume as it wurk dat de klant mei elke rige docht. Behâld it bedoelde resultaat, want in rapport kin detail nedich wêze dat in gearfetting op it skerm net hat.

Foar werhelbere eksporten kin in goedkarde útfieringsplak tichtby de databank in definiearre útfier skriuwe dy’t dan ien kear levere wurdt. Dat feroaret de wurkstream en syn tagongskontrôles, en it is gjin tastimming om in ûnbeheinde dump op in dielde host te litten.

Kompresje is net de standertreparaasje. Stipe en feiligens ôfhinkje fan it eigentlike protokol en de útfiering, en in komprimearre stream dy’t de klant stadich útpekt, kin de belibbing minder meitsje. Mjit earst de faze en kies dan in stipe feroaring foar dy faze.