Prečo sa zhovorčivá SQL aplikácia plazí cez VPN a čo sa oplatí zoskupovať

Formulár, ktorý sa v lokálnej sieti otvorí za menej ako sekundu, cez VPN trvá päť sekúnd, zatiaľ čo kopírovanie súboru na tom istom spoji ide plnou rýchlosťou. Rozdiel nie je v šírke pásma. Formulár čaká na postupnosť odpovedí a v každom kroku platí celú spiatočnú cestu, kým kopírovanie súboru drží bajty nepretržite v pohybe. Spočítajte tie čakania, skôr než sa dotknete prístupovej linky.

Príznakom je obrazovka, nie dopyt

Každý dopyt na tej obrazovke môže byť rýchly a obrazovka môže byť napriek tomu pomalá, pretože súčet je súčtom čakaní, nie súčtom časov vykonávania. Príkaz, ktorý beží dve milisekundy, stále stojí celú spiatočnú cestu, keď klient musí dostať výsledok pred odoslaním ďalšieho. Na trase so štyridsiatimi milisekundami latencie sa sto závislých volaní nazbiera na približne štyri sekundy, kým sa začne akákoľvek práca na vykresľovaní. Táto aritmetika je model čakania, nie meranie vášho spoja.

Preto test rýchlosti vyzerá nevinne. Hromadný prenos meria priepustnosť, zhovorčivý formulár meria latenciu a VPN môže byť vynikajúca v jednom a pritom zostať obyčajná v druhom. Diagnostikovať obrazovku preto znamená merať obrazovku, nie spoj.

Zapíšte čas od začiatku do konca jednej používateľskej akcie, skôr než čokoľvek zmeníte. To číslo je jediná základňa, ktorá vám povie, či neskoršia oprava zabrala.

Spočítajte sekvenčné čakania v jednej používateľskej akcii

Instrumentujte klienta namiesto hádania. V psql \timing on vypisuje uplynutý čas každého príkazu a EXPLAIN (ANALYZE, BUFFERS) ukazuje, koľko z toho času server skutočne strávil prácou.

Rozdiel medzi týmito dvoma číslami je vaša sieťová a klientska réžia. Ak sa príkaz vykoná za dve milisekundy a klient zaznamená šesťdesiat, zvyšných päťdesiatosem je cesta a lokálne spracovanie a žiadny index ich neodstráni. Zopakujte toto porovnanie pre každý príkaz, ktorý obrazovka vydá, a sčítajte rozdiely, nie časy vykonávania.

Zapíšte výsledok ako počet sekvenčných čakaní. Práve túto veličinu dokážu znížiť ďalšie dve časti a je to číslo, o ktorom sa dá hádať s dôkazmi.

Zoskupte nezávislé volania, ponechajte závislé

Dva príkazy, ktoré nečítajú navzájom svoj výsledok, môžu cestovať spolu a byť vyzdvihnuté raz, čo premení dve čakania na jedno. Dva príkazy, kde druhý potrebuje hodnotu prvého, to nemôžu, pretože závislosť je skutočná a zoskupenie by zmenilo to, čo program robí. Pred prepísaním čohokoľvek roztrieďte volania do tých dvoch kôp a veľkosť každej kopy vám povie, čo je možné.

Práca na množine odstraňuje čakania dôkladnejšie ako zoskupovanie. Jeden dopyt, ktorý vráti riadky, ktoré slučka ťahala po jednom, odstráni aj slučku, aj spiatočné cesty. Hľadajte najprv slučku, pretože zvyčajne prináša väčší zisk a je to ľahšie skontrolovateľná zmena.

Dávka stále musí zachovať spracovanie chýb a hranice transakcií. Spájanie nesúvisiacich príkazov do jedného reťazca nie je bezpečná optimalizácia a dávka, ktorá skrýva zlyhaný príkaz za úspešným odoslaním, je horšia než ušetrené čakania.

Používajte spojenia znova, skôr než kúpite šírku pásma

Nové spojenie stojí rozlíšenie mena, potrasenie rukou TCP, vyjednávanie TLS a overenie identity, a na trase s vysokou latenciou je každé z toho ďalšou spiatočnou cestou pred spustením prvého dopytu. Pools pripojení existujú preto, aby sa ten náklad platil raz na proces, nie raz na volanie.

V ADO.NET zatvorenie alebo dispose spojenia z poolu ho vráti na opätovné použitie namiesto otvorenia nového fyzického, takže vzor, ktorý vyzerá ako únik, je často správne použitie. Overte, či sa pool skutočne používa, namiesto predpokladu: logujte vytváranie fyzických spojení alebo sledujte počet relácií na serveri, kým obrazovka beží. Usmernenia k výkonu SQL hovoria to isté o znižovaní spiatočných ciest a zoskupovaní častých ad hoc volaní, s príkladmi špecifickými pre službu, ktoré by ste mali preniesť na svoje vlastné nasadenie.

Pooling odstraňuje náklady na nastavenie a necháva sekvenčné čakania dopytov nedotknuté. Je to predpoklad čistého merania, nie samostatná oprava.

Zvážte presun vykonávania bližšie k dátam

Spúšťanie aplikácie blízko databázy nahradí mnohé vzdialené výmeny s databázou jedinou vzdialenou reláciou zobrazenia. Pre zhovorčivú záťaž to môže byť veľká zmena a je to prevádzková zmena rovnako ako výkonová: správa relácií, kontrola prístupu, nasadzovanie softvéru a používateľská skúsenosť sa všetky presúvajú spolu s aplikáciou.

Zmerajte skutočné rozhranie a dáta, ktoré prenáša, skôr než predpokladáte, že niektorý smer je rýchlejší. Relácia vzdialenej plochy prenáša pixely a obrazovka s hustou grafikou môže na tej istej trase dopadnúť horšie než dopyty, ktoré nahradila, najmä keď klient nepretržite prekresľuje.

Potom zopakujte pôvodnú akciu a porovnajte tri čísla: sekvenčné čakania, objem výsledkov a čas dokončenia od začiatku do konca. Zlepšenie, ktoré mení meranú používateľskú úlohu a pritom zachováva správnosť dát a prístupovú politiku, je to, ktoré sa oplatí ponechať.