Zašto SQL aplikacija s mnogo upita puže preko VPN-a i šta treba objediniti u pakete

Obrazac koji se na lokalnoj mreži prikaže za manje od sekunde preko VPN-a traje pet sekundi, dok kopiranje datoteke na istoj vezi ide punom brzinom. Razlika nije u propusnosti. Obrazac čeka niz odgovora i plaća puni krug na svakom koraku, dok kopiranje datoteke drži bajtove neprekidno u pokretu. Prebrojte 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 vrijeme zbir čekanja, a ne zbir vremena izvršavanja. Naredba koja se izvrši za dvije milisekunde i dalje košta cijeli krug kada klijent mora primiti njen rezultat prije nego što pošalje sljedeću. Na putu sa četrdeset milisekundi kašnjenja stotinu zavisnih poziva skupi se na oko č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 nedužno. Veliki prijenos mjeri propusnost, obrazac s mnogo upita mjeri kašnjenje, a VPN može biti odličan u jednom i prosječan u drugom. Zato dijagnostika ekrana znači mjerenje ekrana, a ne veze.

Zabilježite vrijeme od početka do kraja za jednu korisničku radnju prije nego što bilo šta promijenite. Taj broj je jedina osnovna linija koja vam može reći je li kasnija popravka uspjela.

Prebrojte uzastopna čekanja u jednoj korisničkoj radnji

Mjerite u klijentu umjesto da nagađate. U psql-u \timing on ispisuje proteklo vrijeme svake naredbe, a EXPLAIN (ANALYZE, BUFFERS) pokazuje koliko je od tog vremena server zaista potrošio na posao.

Razlika između ta dva broja je vaš mrežni i klijentski trošak. Ako se naredba izvrši za dvije milisekunde, a klijent zabilježi šezdeset, preostalih pedeset i osam su putovanje i lokalna obrada i nijedan indeks ih neće ukloniti. Ponovite to poređenje za svaku naredbu koju ekran izdaje i sabirajte razlike, a ne vremena izvršavanja.

Zapišite rezultat kao broj uzastopnih čekanja. To je veličina koju sljedeća dva odjeljka mogu smanjiti, i to je broj o kojem možete raspravljati s dokazima.

Objedinite nezavisne pozive, zadržite zavisne

Dvije naredbe koje ne čitaju rezultate jedna druge mogu putovati zajedno i biti prikupljene jednom, što dva čekanja pretvara u jedno. Dvije naredbe kod kojih drugoj treba vrijednost prve ne mogu, jer je zavisnost stvarna i objedinjavanje bi promijenilo ono što program radi. Razvrstajte pozive u te dvije gomile prije nego što bilo šta prepišete, a veličina svake gomile vam kaže šta je moguće.

Rad zasnovan na skupovima uklanja čekanja temeljitije od objedinjavanja. Jedan upit koji vraća redove koje je petlja dohvaćala jedan po jedan uklanja i petlju i krugove. Prvo tražite petlju, jer je ona obično veća dobit i lakša promjena za pregled.

Paket i dalje mora sačuvati obradu grešaka i granice transakcija. Spajanje nepovezanih naredbi u jedan niz nije sigurna optimizacija, a paket koji skriva neuspjelu naredbu iza uspješnog slanja gori je od čekanja koja je uštedio.

Ponovo koristite veze prije nego što kupite propusnost

Nova veza košta razrješavanje imena, TCP rukovanje, TLS pregovaranje i provjeru identiteta, a na putu s velikim kašnjenjem svako od toga je još jedan krug prije nego što se pokrene prvi upit. Skupovi veza postoje da se taj trošak plati jednom po procesu, a ne jednom po pozivu.

U ADO.NET-u zatvaranje ili odlaganje veze iz skupa vraća je za ponovnu upotrebu umjesto otvaranja nove fizičke veze, pa je obrazac koji izgleda kao curenje često ispravna upotreba. Provjerite da se skup zaista koristi umjesto da to pretpostavite: bilježite stvaranje fizičkih veza ili pratite broj sesija na serveru dok ekran radi. Smjernice za performanse SQL-a govore isto o smanjenju krugova i objedinjavanju čestih ad hoc poziva, s primjerima za pojedinu uslugu koje treba primijeniti na svoju implementaciju.

Objedinjavanje uklanja trošak postavljanja i ostavlja uzastopna čekanja upita netaknutima. To je preduvjet za čisto mjerenje, a ne popravka sama po sebi.

Odmjerite premještanje izvršavanja bliže podacima

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

Izmjerite stvarno sučelje i podatke koje prenosi prije nego što pretpostavite da je bilo koji smjer brži. Udaljena sesija radne površine prenosi piksele, a ekran s gustim grafikama može na istoj vezi raditi lošije od upita koje je zamijenio, posebno kada klijent neprekidno iscrtava iznova.

Zatim ponovite izvornu radnju i uporedite tri broja: uzastopna čekanja, obim rezultata i vrijeme dovršetka od početka do kraja. Poboljšanje koje mijenja mjereni korisnički zadatak uz očuvanje ispravnosti podataka i politike pristupa je ono koje vrijedi zadržati.