Keširanje sadržaja
Kod kompleksnijih sajtova i sajtova koji imaju veću posetu, generisanje sadržaja stalnim povlačenjem podataka iz baze može ozbiljno da ugrozi brzinu otvaranja stranica sajta, pa i njegovu generalnu stabilnost. Jedan od načina rešavanja ovog problema je naravno optimizacija SQL upita, ali često je brži i efikasniji način (ili bar komplementarni) – keširanje sadržaja.
Reč Keš (caché) je francuskog porekla i označava nešto što je skriveno, keš memorija je skrivena memorija u kojoj se čuvaju već pripremljeni podaci.
Keširanje sadržaja je najefikasnije za podatke koji se retko menjaju (na primeru sajta biblioteke to je opis knjige, autor i drugi podaci o knjizi).
Keširanje u najprostijem obliku je proces čuvanja jednom generisane stranice ili dela stranice na nekom medijumu za čuvanje podataka (disk, memorija, …) i njegovo prikazivanje direktnim povlačenjem sa medijuma, umesto ponovnog generisanja nizom upita u bazu podataka.
Samo keširanje je široka tema, ali moja preporuka za manje i srednje zahtevne sajtove je korišćenje Cache_litePear paketa za keširanje na disku
Primer prostog načina korišćenja cache_lite sistema može da izgleda ovako:
<?php
require_once ‘Cache/Lite.php’; //Uvuci cache_lite klase
$options = array(
‘cacheDir’ => ‘cache/ZaStranice/’,
‘writeControl’ => ‘true’,
‘readControl’ => ‘true’,
‘fileNameProtection’ => false,
‘readControlType’ => ‘md5’,
‘hashedDirectoryLevel’ => 0,
‘lifetime’ => 3600,
‘automaticSerialization’ => true
);//Definicija parametara kesiranja
$cacheOutput = new Cache_Lite_Output($options);//Instanciranje objekta za upravljanje kesiranjem
if(!$cacheOutput->start(“IDStranice”, “GrupaStranice”)) { //Ako sadrzaj nije bio kesiran do sada, generisi ga na standardan nacin ?>
HTML sadržaj
<?php $cacheOutput->end();//Pisanje generisanog sadrzaja na disk radi kasnijeg koriscenja }?>
U gornjem primeru cache_lite objekat proverava da li je sadržaj ranije iskeširan, ukoliko jeste – keširani sadržaj će biti dovučen iz direktorijuma cache/ZaStranice/, a ukoliko nije – generisaće sadržaj podacima iz baze i snimiće ga u dati direktorijum. Keširani sadržaj je moguće ručno invalidirati (svodi se na brisanje keš fajlova) u slučaju da se podaci promene. Takođe je moguče definisati interval vremena nakon koga će se keširani sadržaj automatski invalidirati, u gornjem primeru je to 3600 sekundi (jedan sat).
Keširanje na disku može da izazove probleme u slučaju velikog broja čitanja sa deljenog diska (Npr NFS), i trebalo bi ga izbegavati u tom slučaju (eventualno koristiti lokalne diskove).
U slučaju zahtevnijeg sistema, možete proučiti i koristiti Redis key-value repozitorijum za keširanje u memoriji.
Keširanje sadržaja koji se retko menja je korisno za rasterećenje baze podataka (u slučaju da vam je ona usko grlo).
Ukoliko imate pitanja ili želite da podelite svoja iskustva i preporuke,
tvitamo se na @LimundoGradnja
Sta sad ti naprica. Meni ovo sve spansko selo :))
A da li je to kesiranje preporucljivo ako se redovno iz brauzera brise kes memorija zajedno sa istorijom pregledanja??? da li je moguce da neka web aplikacija koristi duple baze jedna na racunaru korisnika = to bi bila kes memorija a druga na serveru-mysql… radi brzeg otvaranja i postojanja baze i kad server neradi i obratno da se po ukljucenju servera refreshuje i obnovi kes memorija ukoliko je korisnik izbrisao?
Kes memorija u browseru je na klijentskoj strani i nije vezana za kesiranje na serverskoj strani koje je opisano u ovom blogu. Kesiranje na serveru je uvek preporucljivo zbog ustede resursa i povecanja brzine.
Sto se tice drugog pitanja – generalno ako server ne radi nece raditi ni web aplikacija koja se “vrti” na njemu, tako da je prakticno jako tesko napraviti funkcionalnu arhitekturu koju si opisao.