Datum objave: tbd
Verzija aplikacije: 3.8.0
Nove funkcionalnosti i ispravke:
1. Optimizacija upita za VOD kataloge: Trenutni upiti koji se koriste za prikaz VOD (Video on Demand) kataloga previše opterećuju bazu podataka, što može uticati na performanse aplikacije i backend sistema.
U prošlosti smo već implementirali optimizaciju keširanjem podataka na klijentskoj strani za API poziv koji vraća kataloge iz video kluba. Međutim, i dalje povremeno primećujemo zagušenje konekcija, što rezultati analize ukazuju da je često povezano upravo sa ovim API pozivom, koji se najčešće koristi.
Kako bismo dodatno smanjili opterećenje, primenili smo rešenje koje na serveru kešira brojanje naslova u katalogu na period od 60 minuta, prilagođeno zonama i profilima. Ovo optimizuje izvršenje, jer različiti brojevi naslova u katalozima zavise od specifičnih zona i profila, što je ranije pravilo značajan problem. Sada će samo jedan korisnik u 60 minuta koji napravi API poziv da izbroji naslove, dok će ostali povlačiti standardno iz keša.
Ispod je prikazan primer API poziva za izlistavanje programske šeme jednog kanala. Iako ovaj API poziv generalno nema poteškoća sa preuzimanjem podataka iz baze, logovi pokazuju da je u određenim slučajevima potrebno i do 3 sekunde za njegovo izvršenje, dok je prosečno vreme izvršenja za druge API pozive ispod 100 ms. Ovaj nesklad ukazuje na potrebu za dodatnim optimizacijama.
Predloženo rešenje uključuje optimizaciju upita koji zahtevaju više vremena za izvršenje, poput onih za VOD kataloge, što je u ovom slučaju već implementirano. Pored toga, postoji mogućnost primene dodatnih rešenja koja mogu doprineti daljem unapređenju performansi. Detalji o ovim rešenjima biće opisani u nastavku.
2. Povećanje broja konekcija u JDBC za MyBatis: Jedno od rešenja koje može doprineti smanjenju zadržavanja konekcija tokom izvršavanja zahtevnih upita jeste povećanje broja dostupnih konekcija u JDBC za MyBatis. Trenutno je postavljeno podrazumevanih 10 konekcija. Međutim, s obzirom na performanse našeg servera, verujemo da može podržati veći broj konekcija.
Optimalan broj konekcija može se odrediti primenom odgovarajuće formule, koja uzima u obzir performanse servera i omogućava balansiranje opterećenja kako bi se postigla maksimalna efikasnost sistema. Detaljnije analize i prilagođavanja ovog parametra biće obavljene u narednim koracima.
connections = ((core_count * 2) + effective_spindle_count)
Naš server poseduje 16 jezgara, što omogućava aplikaciji da održava do 32 otvorene konekcije prema bazi podataka. Ovo povećanje ne samo da bi omogućilo bolje rukovanje trenutnim opterećenjem, već bi nas pripremilo i za budući rast saobraćaja ka sajtu.
Podaci iz monit alata, koji koristimo za praćenje performansi servera, takođe ukazuju na to da trenutni kapacitet servera nije u potpunosti iskorišćen, što pruža prostor za implementaciju ovog unapređenja bez značajnog uticaja na resurse servera. Vizualni prikaz trenutnog stanja servera dostupan je u nastavku.
Predlog za povećanje broja konekcija i razdvajanje konekcionih poolova
3. Povećanje broja konekcija u postojećem poolu
Trenutno je postavljeno 10 konekcija u konekcionom poolu, što povremeno dovodi do zagušenja prilikom izvršavanja zahtevnih upita. Predlog je da se broj konekcija poveća na 20, što bi omogućilo veću propusnost i smanjilo zadržavanje konekcija, čime bi se postiglo značajno rasterećenje sistema i bolje upravljanje zahtevima ka bazi podataka. Ovo povećanje predstavlja korak ka prilagođavanju kapacitetima našeg servera sa 16 jezgara i pripremi za budući rast saobraćaja.
4. Razdvajanje upita za VOD sadržaje i pretrage u poseban konekcioni pool
Planirano je razdvajanje upita za VOD sadržaje i pretrage u poseban konekcioni pool kako bi se intenzivni zahtevi za ove operacije izolovali od ostalih upita prema bazi. Ova izmena ima za cilj:
- Poboljšanje performansi baze podataka i aplikacije.
- Sprečavanje da zahtevni upiti za VOD sadržaje i pretrage utiču na performanse ostalih operacija.
- Omogućavanje boljeg upravljanja konekcionim poolovima.
Trenutno je samo upit za pretragu izdvojen u poseban pool, dok upiti za VOD sadržaje još uvek nisu. U budućnosti je planirano kompletno izdvajanje svih upita vezanih za VOD sadržaje, što će zahtevati dodatne tehničke izmene, ali će pružiti značajne benefite u performansama.
Ova rešenja zajedno predstavljaju značajan korak ka unapređenju kapaciteta i stabilnosti sistema, pripremajući nas za efikasnije rukovanje sve većim opterećenjem.
Ispod je slika gde se vidi da trenutno API za pretragu i VOD sadržaje trenutno imaju najveći udeo, i ako naravno oni nisu API pozivi koji se najčešće okidaju:
5. Rešavanje problema sa Hazelcast-om: Identifikovan je problem pri pokretanju midlevera, gde je prvi korisnik koji kreira sesiju mogao izazvati poteškoće za ostale korisnike u slučaju da ima manje od 5 servisa. Ovo je sada rešeno kako bi se obezbedila stabilnost i doslednost u radu aplikacije za sve korisnike.
6. Onemogućeno keširanje praznih odgovora u API response-u: Do sada je klijent imao mogućnost keširanja praznih odgovora iz API-ja, što je povremeno uzrokovalo probleme sa prikazom podataka ili ponovnim pokušajem učitavanja. Uvedene su izmene kako bi se onemogućilo keširanje praznih odgovora, čime se osigurava tačnost i ažurnost prikazanih informacija.
7. Izmena logike za invalidaciju keša prilikom prelaska iz jednog u drugi dan u programskoj šemi: Prethodna logika invalidacije keša programske šeme dovodila je do kašnjenja u prikazu važeće programske emisije. Kada je programska šema na serveru postala nevažeća, keš je bio invalidiran, ali tek u narednom API pozivu korisniku je vraćena ažurirana programska šema. Sada je implementirano rešenje koje osigurava da korisnik već u prvom odgovoru dobije važeću programski šemu sa trenutnom emisijom, čime se značajno poboljšava korisničko iskustvo.
Napomena: Gde je primenljivo, dodaćemo slike i vizuelne prikaze novih funkcionalnosti i popravki.
Feedback: Vaše mišljenje nam je važno! Ako imate komentare ili sugestije, slobodno ih podelite sa nama.