Zašto se brbljiva SQL aplikacija vuče preko VPN-a i što vrijedi grupirati

Obrazac koji se u lokalnoj mreži otvara za manje od jedne sekunde preko VPN-a traje pet sekundi, dok kopija datoteke na istoj vezi ide punom brzinom. Razlika nije propusnost. Obrazac čeka niz odgovora i na svakom koraku plaća cijelo povratno putovanje, dok kopija datoteke neprekidno drži bajtove u letu. Prebrojite ta čekanja prije nego što dotaknete pristupnu liniju.

Simptom je ekran, a ne upit

Svaki upit na tom ekranu može biti brz, a ekran i dalje može biti spor, jer je ukupno zbroj čekanja, a ne zbroj vremena izvršavanja. Naredba koja se izvršava za dvije milisekunde ipak košta cijelo povratno putovanje kada klijent mora primiti rezultat prije nego pošalje sljedeću. Na putu s kašnjenjem od četrdeset milisekundi sto zavisnih poziva skupi se na otprilike četiri sekunde prije nego što počne bilo kakav rad na iscrtavanju. Ta aritmetika je model čekanja, a ne mjerenje vaše veze.

Zato test brzine izgleda nevino. Veliki prijenos mjeri propusnost, brbljivi obrazac mjeri kašnjenje, a VPN može biti izvrstan u jednom i ostati običan u drugom. Dijagnosticirati ekran stoga znači mjeriti ekran, a ne vezu.

Zabilježite vrijeme od početka do kraja jedne korisničke radnje prije nego što bilo što promijenite. Taj je broj jedina osnovica koja može reći je li kasnija popravka uspjela.

Prebrojite uzastopna čekanja u jednoj korisničkoj radnji

Instrumentirajte klijenta umjesto da nagađate. U psql-u \timing on ispisuje proteklo vrijeme svake naredbe, a EXPLAIN (ANALYZE, BUFFERS) pokazuje koliko je od tog vremena poslužitelj stvarno potrošio na posao.

Razlika između tih dvaju brojeva vaš je mrežni i klijentski trošak. Ako se naredba izvršava za dvije milisekunde, a klijent zabilježi šezdeset, preostalih pedeset i osam su put i lokalna obrada, i nijedan indeks ih neće ukloniti. Ponovite tu usporedbu za svaku naredbu koju ekran izdaje i zbrajajte razlike, a ne vremena izvršavanja.

Zapišite rezultat kao broj uzastopnih čekanja. Upravo tu veličinu sljedeća dva dijela mogu smanjiti, i to je broj o kojem se može raspravljati s dokazima.

Grupirajte nezavisne pozive, zadržite zavisne

Dvije naredbe koje ne čitaju rezultat jedna druge mogu putovati zajedno i biti prikupljene jedanput, što pretvara dva čekanja u jedno. Dvije naredbe gdje druga treba vrijednost prve ne mogu, jer je zavisnost stvarna i grupiranje bi promijenilo ono što program radi. Razvrstajte pozive u te dvije hrpe prije nego što bilo što prepišete, a veličina svake hrpe govori što je moguće.

Rad na skupovima uklanja čekanja temeljitije od grupiranja. Jedan upit koji vraća retke koje je petlja dohvaćala jedan po jedan uklanja i petlju i povratna putovanja. Prvo tražite petlju, jer je obično veći dobitak i lakša promjena za pregled.

Grupa ipak mora sačuvati obradu pogrešaka i granice transakcija. Spajanje nepovezanih naredbi u jedan niz nije sigurna optimizacija, a grupa koja skriva neuspjelu naredbu iza uspješne predaje gora je od čekanja koja je uštedjela.

Ponovno upotrijebite veze prije nego što kupite propusnost

Nova veza košta razrješavanje imena, TCP rukovanje, TLS pregovaranje i autentifikaciju, a na putu s visokim kašnjenjem svako je od toga još jedno povratno putovanje prije nego što se pokrene prvi upit. Pools veza postoje da bi se taj trošak platio jedanput po procesu, a ne jedanput po pozivu.

U ADO.NET-u zatvaranje ili dispose veze iz poola vraća je za ponovnu upotrebu umjesto da otvori novu fizičku, pa je uzorak koji izgleda kao curenje često ispravna upotreba. Provjerite je li pool doista u upotrebi umjesto da to pretpostavite: bilježite stvaranje fizičkih veza ili promatrajte broj sesija na poslužitelju dok ekran radi. Smjernice za SQL izvedbu govore isto o smanjenju povratnih putovanja i grupiranju čestih ad hoc poziva, s primjerima specifičnima za uslugu koje biste trebali preslikati na vlastitu implementaciju.

Pooling uklanja trošak postavljanja i ostavlja uzastopna čekanja upita netaknutima. To je preduvjet za čisto mjerenje, a ne samostalna popravka.

Odmjerite premještanje izvršavanja bliže podacima

Pokretanje aplikacije blizu baze podataka zamjenjuje mnoge udaljene razmjene s bazom jednom udaljenom sesijom prikaza. Za brbljivo opterećenje to može biti velika promjena, i to je operativna promjena koliko i promjena izvedbe: upravljanje sesijama, kontrola pristupa, implementacija softvera i korisničko iskustvo svi se sele zajedno s aplikacijom.

Izmjerite stvarno sučelje i podatke koje prenosi prije nego što pretpostavite da je neki smjer brži. Sesija udaljenog radnog stola prenosi piksele, a ekran s gustom grafikom može raditi lošije na istom putu od upita koje je zamijenio, osobito kada klijent neprestano ponovno iscrtava.

Zatim ponovite izvornu radnju i usporedite tri broja: uzastopna čekanja, obujam rezultata i vrijeme dovršetka od početka do kraja. Poboljšanje koje mijenja mjerenu korisničku zadaću uz očuvanje točnosti podataka i pristupne politike ono je koje vrijedi zadržati.