Granda SQL-resulto tra VPN: kie la vicoj atendas

Pridemandoj povas finiĝi en milisekundoj kaj tamen daŭri minutojn por atingi tekkomputilon tra VPN. La servilo skribas vicojn en bufrojn, la konekto transportas ilin, kaj la kliento konsumas ilin, kaj tiuj etapoj interkovriĝas anstataŭ sinsekvi. Iu ajn el ili povas fariĝi la limo. Trovu la etapon, kiu vere atendas, antaŭ ol ŝanĝi bendolarĝon aŭ ŝalti kunpremadon.

Tri etapoj, unu klikhorloĝo

Dividu la tempomezurilon en du nombrojn kun malsamaj signifoj: la momento, kiam la unua vico disponeblas, kaj la momento, kiam la lasta vico estas konsumita. Krado, kiu pentras la unuan paĝon, pruvas nur, ke la pridemando komenciĝis. La tempo de la kompleta rezulto estas tio, kion la uzanto spertas kiam li eksportas aŭ rulumas ĝis la fino.

Notu ambaŭ nombrojn kune kun la pridemanda teksto, la parametroj kaj la konektaj agordoj. Sen tiu kunteksto la komparo estas inter du malsamaj taskoj, ne inter du lokoj.

Legu la atendo antaŭ la reto

SQL Server skribas rezultajn vicojn en eligajn bufrojn, por ke la kliento ilin prenu, kaj kliento, kiu konsumas malrapide, povas igi la servilon atendi tiun sendon. La atendotipo estas ASYNC_NETWORK_IO, kaj la problemtraka noto de Microsoft listigas grandajn rezultojn kaj prilaboradon ĉe la kliento inter la kaŭzoj. La atendo diras, ke la sendovojo estas blokita, ne kial.

Malrapida VPN povas kontribui, sed ankaŭ kliento, kiu formatas ĉiun vicon, skribas en dosieron aŭ paŭzas inter aroj. La nomo de la atendo estas montrilo al la sekva mezurado, ne verdikto pri la ligilo.

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

Legu la nombrilon dum la limigita laborŝarĝo funkcias, ne post senokupa horo, ĉar akumulaj nombriloj miksas ĉiun seancon ekde la komenco de la instanco. Komparu la delton dum la kurado anstataŭ la tutan vivodaŭran sumon. Kreskanta delto dum la transigo mallarĝigas la demandon al konsumado aŭ liverado.

Metu ambaŭ klientojn sur la saman horloĝon

Rulu limigitan laborŝarĝon de kliento proksima al la datumbazo kaj de la fora kliento. Tenu la pridemandan tekston, parametrojn, rezultan grandecon kaj konektajn agordojn identaj. Uzu la saman mezuron ĉe ambaŭ flankoj, ĉar la plenumtempo de la servilo, la vidigotempo de la krado kaj la eksporttempo estas tri malsamaj horloĝoj. Kompari nombron ĉe la servila flanko kun eksporta tempomezurilo ĉe la klienta flanko donas konkludon, kiun oni ne povas testi.

Kiam la vojo ŝajnas respondeca, petu la retposedanton observi perdojn, resendojn kaj atingitan trafluon por tiu specifa fluo dum la transigo funkcias. Ĝenerala rapidotesto eble uzas alian itineron, finpunkton aŭ samtempecan ŝablonon. Malgranda sukcesa peto diras malmulte pri daŭra rezulta transigo.

Tranĉu bajtojn antaŭ ol kulpigi la vojon

Filtrado, agregado kaj elekto nur de la bezonataj kolumnoj malpliigas kaj la transigvolumenon kaj la laboron, kiun la kliento faras kun ĉiu vico. Konservu la celitan rezulton, ĉar raporto eble bezonas detalojn, kiujn resumo sur la ekrano ne havas.

Por ripeteblaj eksportoj, aprobita plenumloko proksime al la datumbazo povas skribi difinitan eligon, kiu poste estas liverata unufoje. Tio ŝanĝas la laborfluon kaj ĝiajn alirregulojn, kaj ĝi ne estas permeso lasi senliman elĵetaĵon sur komunan gastiganton.

Kunpremado ne estas la defaŭlta riparo. Subteno kaj sekureco dependas de la reala protokolo kaj deplojo, kaj kunpremita fluo, kiun la kliento malrapide malpakas, povas plimalbonigi la sperton. Mezuru unue la etapon, poste elektu subtenatan ŝanĝon por tiu etapo.