Optimizacija Django aplikacija: ORM, cache i SQL upiti

Django aplikacija može dobro raditi s nekoliko stotina zapisa, a zatim usporiti kada podaci narastu ili korisnici počnu intenzivno filtrirati tablice. Prije povećanja snage servera treba pronaći stvarne uzroke. U mnogim slučajevima najveći dobitak dolazi iz bolje uporabe ORM-a, indeksa i promišljenog cachea.

Prvo izmjerite spor zahtjev

Na produkcijskom sustavu pratite trajanje najvažnijih ruta, broj SQL upita i korištenje resursa. U razvojnom okruženju Django Debug Toolbar može pomoći pronaći nepotrebna ponavljanja, dok se na bazi mogu koristiti alati za analizu izvršavanja upita. Mjerite reprezentativne podatke, ne samo praznu testnu bazu.

Nemojte optimizirati svaki dio aplikacije jednakim intenzitetom. Najprije pronađite zahtjeve koje korisnici često otvaraju i čiji odziv stvarno otežava rad.

N+1 upiti: mali kod, veliki problem

Ako u petlji čitate povezani objekt za svaki redak, ORM može napraviti jedan upit za listu i zatim dodatni upit za svaki zapis. To je klasični N+1 problem. Kod veza prema jednom objektu često pomaže select_related(), a za mnogostruke veze prefetch_related().

narudzbe = Narudzba.objects.select_related("kupac").all()

Primjer pretpostavlja da model Narudzba ima vezu kupac. Nije poanta dodati ove metode posvuda, nego njima riješiti konkretan obrazac upita. Pretjerani prefetch može nepotrebno povećati potrošnju memorije.

Indeksi i paginacija

Ako se tablica redovito filtrira po statusu i datumu, provjerite ima li prikladan indeks i koristi li ga baza. Odgovor daje plan izvršavanja, ne samo intuicija. Uvijek uravnotežite brža čitanja s troškom zapisivanja i dodatnim prostorom.

Za velike popise izbjegavajte dohvaćanje desetaka tisuća redaka odjednom. Uvedite paginaciju i razuman broj stupaca, a složene izvoze podataka premjestite u pozadinski zadatak. Ako korisnik traži sve podatke, ponudite pripremu datoteke umjesto da preglednik čeka na velik odgovor.

Cache može pomoći, ali i stvoriti pogreške

Predmemoriranje odgovora ili skupih izračuna smisleno je kada se podaci ne mijenjaju često. Međutim, cache personaliziranih stranica može nenamjerno prikazati sadržaj drugom korisniku ako je loše ključan. Definirajte rok trajanja, pravila invalidacije i ovlasti pristupa prije uključivanja cachea.

Posebno je korisno predmemorirati javne statistike ili rezultate čija neznatna zastarjelost nije problem. Za stanje narudžbe ili raspoloživost termina često treba svjež podatak iz baze.

Izmjerite rezultat promjene

Nakon svake optimizacije usporedite vrijeme odgovora, broj upita, potrošnju memorije i ponašanje pri očekivanom opterećenju. Važno je provjeriti i ispravnost poslovnih pravila, jer brži, ali pogrešan rezultat nije napredak.

Dobra optimizacija Djanga postupna je i mjerljiva. Prije skupljeg servera iskoristite znanje o tome što aplikacija stvarno radi.

Primjer sporog popisa narudžbi

Korisnici prijavljuju da se tablica narudžbi otvara deset sekundi. Razvojni tim prvo izmjeri zahtjev i vidi velik broj SQL upita za podatke kupaca. Uvođenjem prikladnog select_related() poziva broj upita može se značajno smanjiti. Ako se zatim otkrije da se dohvaća više tisuća redaka, dodaje se paginacija. Tek nakon tih promjena ima smisla procijeniti treba li promijeniti indeks ili povećati resurse baze.

Jedna optimizacija može pogoršati drugi dio sustava, pa testovi funkcionalnosti i mjerenje ukupnog opterećenja moraju pratiti svaku promjenu. Tako se izbjegava ubrzavanje jednog izvještaja na štetu upisa.

Česta pitanja

Je li cache uvijek poželjan? Ne. Podaci s kratkim rokom valjanosti ili strogo individualnim pristupom zahtijevaju oprez.

Kada dodati indeks? Kada plan izvršavanja i stvarni upiti pokažu da je koristan.

Pomaže li brži server? Može, ali najprije treba ukloniti nepotrebne upite i velike odgovore. Time često odgađate skuplju infrastrukturu.

Kontrolna lista za optimizaciju Django sustava

Optimizacija počinje mjerenjem stvarnog opterećenja. Najvažnije je utvrditi je li usko grlo u bazi, aplikacijskom kodu, serveru ili pregledniku. Promjene treba uvoditi postupno kako bi se mogao pripisati stvarni učinak svakog zahvata. To smanjuje opasnost da nova optimizacija pokvari postojeću funkcionalnost.

• Koje su najsporije poslovno važne stranice i koliko SQL upita proizvodi svaki njihov tipičan zahtjev?
• Postoje li N+1 obrasci dohvaćanja koje možemo ukloniti primjerenom uporabom select_related() i prefetch_related()?
• Jesu li indeksi odabrani na temelju stvarnih filtera i planova izvršavanja, uz provjeru troška upisa?
• Prikazuje li aplikacija nepotrebno velike popise umjesto paginacije i filtriranja na strani baze?
• Jesu li cache ključevi i rokovi valjanosti osmišljeni tako da ne mogu otkriti podatke pogrešnom korisniku?
• Kako ćemo usporediti rezultat prije i poslije optimizacije te osigurati da važna poslovna pravila i dalje vrijede?

Najbolji zahvat nije uvijek najveća promjena koda, nego ona koja rješava izmjereno ograničenje s najmanjim rizikom.

Kod cachea koji ovisi o korisniku treba testirati promjene uloge i odjavu. Ako je korisniku ukinuto pravo pristupa, stari predmemorirani odgovor ne smije nastaviti otkrivati podatke. Sličnu pažnju posvetite izvozu većih izvještaja, gdje se rezultati često pohranjuju u privremene datoteke.