Bakit gumagapang sa VPN ang isang madaldal na SQL app at ano ang dapat i-batch

Ang isang form na bumubukas sa wala pang isang segundo sa isang lokal na network ay tumatagal ng limang segundo sa VPN, habang ang isang kopya ng file sa parehong link ay tumatakbo sa buong bilis. Ang pagkakaiba ay hindi bandwidth. Naghihintay ang form ng isang pagkakasunod-sunod ng mga sagot at nagbabayad ng buong round trip sa bawat hakbang, habang ang kopya ng file ay patuloy na nagpapanatili ng mga byte sa byahe. Bilangin ang mga paghihintay na iyon bago mo hawakan ang access line.

Ang sintomas ay isang screen, hindi isang query

Ang bawat query sa screen na iyon ay maaaring mabilis at ang screen ay maaari pa ring mabagal, dahil ang kabuuan ay ang kabuuan ng mga paghihintay at hindi ang kabuuan ng mga oras ng execution. Ang isang statement na tumatakbo sa dalawang millisecond ay nagkakahalaga pa rin ng isang buong round trip kapag ang client ay dapat tumanggap ng resulta bago ipadala ang susunod. Sa isang landas na may apatnapung millisecond na latency, ang isandaang dependenteng tawag ay umaabot sa humigit-kumulang apat na segundo bago magsimula ang anumang gawaing pag-render. Ang aritmetikang ito ay isang modelo ng paghihintay, hindi isang sukatan ng iyong link.

Iyon ang dahilan kung bakit ang isang speed test ay mukhang inosente. Ang bulk transfer ay sumusukat ng throughput, ang madaldal na form ay sumusukat ng latency, at ang isang VPN ay maaaring maging mahusay sa isa habang nananatiling karaniwan sa isa. Kaya ang pag-diagnose ng screen ay nangangahulugang pagsukat ng screen at hindi ng link.

Itala ang oras mula simula hanggang matapos ng isang aksyon ng user bago baguhin ang anuman. Ang numerong iyon ang tanging baseline na makapagsasabi kung gumana ang isang susunod na pag-aayos.

Bilangin ang magkakasunod na paghihintay sa isang aksyon ng user

Instrumentuhan ang client sa halip na manghula. Sa psql, ang \timing on ay nagpi-print ng lumipas na oras ng bawat statement, at ang EXPLAIN (ANALYZE, BUFFERS) ay nagpapakita kung gaano kalaki sa oras na iyon ang aktwal na ginugol ng server sa gawain.

Ang puwang sa pagitan ng dalawang numerong iyon ang iyong network at client overhead. Kung ang isang statement ay nag-execute sa dalawang millisecond at ang client ay nagtala ng animnapu, ang natitirang limampu't walo ay paglalakbay at lokal na pagproseso, at walang index ang mag-aalis ng mga iyon. Ulitin ang paghahambing na iyon para sa bawat statement na inilalabas ng screen at pagsamahin ang mga puwang, hindi ang mga oras ng execution.

Isulat ang resulta bilang bilang ng magkakasunod na paghihintay. Iyon ang dami na kayang bawasan ng susunod na dalawang seksyon, at ito ay isang numero na maaari mong pagtalunan nang may ebidensya.

I-batch ang mga independyenteng tawag, panatilihin ang mga dependente

Ang dalawang statement na hindi nagbabasa ng resulta ng isa't isa ay maaaring maglakbay nang magkasama at kolektahin nang isang beses, na ginagawang isa ang dalawang paghihintay. Ang dalawang statement kung saan ang pangalawa ay nangangailangan ng halaga ng una ay hindi maaari, dahil ang dependency ay totoo at ang pag-batch ay magbabago ng ginagawa ng programa. Isaayos ang mga tawag sa dalawang bunton na iyon bago muling isulat ang anuman, at ang laki ng bawat bunton ay nagsasabi kung ano ang posible.

Ang gawaing nakabatay sa set ay nag-aalis ng mga paghihintay nang mas lubusan kaysa sa pag-batch. Ang isang query na nagbabalik ng mga row na kinukuha ng isang loop nang paisa-isa ay nag-aalis ng loop at ng mga round trip. Hanapin muna ang loop, dahil kadalasan ito ang mas malaking pakinabang at ang mas madaling suriin na pagbabago.

Ang isang batch ay kailangan pa ring panatilihin ang paghawak ng error at ang mga hangganan ng transaksyon. Ang pagsasama-sama ng walang kaugnayang statement sa isang string ay hindi isang ligtas na optimisasyon, at ang isang batch na nagtatago ng nabigong statement sa likod ng matagumpay na pagsusumite ay mas masahol pa kaysa sa mga paghihintay na natipid nito.

Gamitin muli ang mga koneksyon bago bumili ng bandwidth

Ang isang bagong koneksyon ay nagkakahalaga ng resolution ng pangalan, TCP handshake, TLS negotiation at authentication, at sa isang landas na may mataas na latency ang bawat isa sa mga iyon ay isa pang round trip bago tumakbo ang unang query. Umiiral ang mga pool ng koneksyon upang bayaran ang gastos na iyon nang isang beses bawat proseso at hindi isang beses bawat tawag.

Sa ADO.NET, ang pagsasara o dispose ng isang naka-pool na koneksyon ay nagbabalik nito para muling gamitin sa halip na magbukas ng bagong pisikal, kaya ang pattern na mukhang pagtagas ay kadalasang tamang paggamit. Tiyakin na ang pool ay talagang ginagamit sa halip na ipagpalagay: i-log ang paglikha ng pisikal na koneksyon, o panoorin ang bilang ng session sa server habang tumatakbo ang screen. Ang gabay sa pagganap ng SQL ay nagsasabi ng parehong punto tungkol sa pagbawas ng mga round trip at pag-batch ng madalas na ad hoc na tawag, na may mga halimbawang partikular sa serbisyo na dapat mong i-map sa iyong sariling deployment.

Ang pooling ay nag-aalis ng gastos sa setup at iniiwan ang magkakasunod na paghihintay ng query na hindi nagalaw. Ito ay isang paunang kundisyon para sa malinis na pagsukat, hindi isang pag-aayos sa sarili nito.

Timbangin ang paglipat ng execution palapit sa data

Ang pagpapatakbo ng application malapit sa database ay pumapalit sa maraming malayong pagpapalitan sa database ng isang malayong display session. Para sa isang madaldal na workload maaaring ito ay isang malaking pagbabago, at ito ay isang pagbabago sa operasyon kasing dami ng pagbabago sa pagganap: pamamahala ng session, kontrol sa access, deployment ng software at karanasan ng user ay lahat gumagalaw kasama ng application.

Sukatin ang aktwal na interface at ang data na inililipat nito bago ipagpalagay na ang alinmang direksyon ay mas mabilis. Ang isang remote desktop session ay naglilipat ng mga pixel, at ang isang screen na may siksik na graphics ay maaaring makagawa nang mas mahina sa parehong landas kaysa sa mga query na pinalitan nito, lalo na kapag ang client ay patuloy na nagre-redraw.

Pagkatapos ay ulitin ang orihinal na aksyon at ihambing ang tatlong numero: magkakasunod na paghihintay, dami ng resulta at oras ng pagkumpleto mula simula hanggang matapos. Ang pagpapabuti na nagbabago sa sinusukat na gawain ng user habang pinapanatili ang kawastuhan ng data at patakaran sa access ang siyang dapat panatilihin.