Cache in PHP

Cache-ul este o zona temporara de stocare de informatii, care duplica niste date considerate originale, creat pentru acces direct si rapid asupra acestor date. Aceasta mapare a datelor fata de locul lor de stocare initial, se face pentru  acele date care sunt greu de accesat in mod direct, care se afla in zone partajate, care ar avea un timp de prelucrare ridicat si care ar fi solicitate in mod frecvent, iar rezultatul ar fi de fiecare data acelasi.

Sisteme de cache se intalnesc implementate in microprocesoare(exemplul fiind cache-ul de nivel 2), in hard disk-uri(pentru a micsora timpul de citire al datelor), in sisteme de management al bazei de date(MySQL va tine in cache rezultatul unei interogari, iar la primirea aceleiasi interogari va returna rezultatul din cache, fara a interoga tabelele in sine), in browser-ele pe car ele folosim zi de zi(Firefox de exemplu isi va face cache la imagini, ca la un refresh sa nu fie nevoit sa le preia de pe server din nou), chiar si Google detine propriul cache din care poate furniza continutul paginilor web.

Asadar, scopul declarat al cache-ului este de a economisi timp.

Teoria Cache-ului

Exista cateva concepte cheie in teoria cache-ului care trebuiesc respectate in implementarea unui astfel de sistem

1. identificatorul unic – care va fi folosit la identificarea elementului in cache
2. durata de viata – defineste cat timp un element din cache va fi considerat valid
3. preluarea conditionata – astfel incat partile din cod care ar accesa informatiile originale sa fie evitate, dar sa si permita reimprospatarea
4. resetarea la cerere – pentru pastrarea consistentei informatiilor din cache cu cele din locatia originala, este necesara posibilitatea ca la o modificare a datelor din aceasta locatie, cache-ul sa fie marcat ca invalid si reconstruit

Astfel, un algoritm general de folosire a cache-urilor ar fi:

• daca elementul din cache cerut de aplicatie exista atunci el va fi returnat intocmai
• daca elementul din cache cerut nu exista atunci datele acelui cache se vor aduce din locatia originala, se va crea elementul corespunzator in cache, iar datele vor fi returnate aplicatiei

Aplicare

Asadar, vom presupune o apicatie web, pentru care avem un numar mare de accesari atat din partea vizitatorilor dar si din partea celor care administreaza respectivul website. Pentru o si mai buna exemplificare, vom considera cazul standard al unui magazin online, in care avem listari de categorii, listari de produse din fiecare categorie si afisari detaliate de produse(pret, descriere, detalii tehnice etc). In spatele site-ului, respectiv in aplicatia de administrare a acestuia, avem un numar de operatori care lucreaza necontenit la imbunatatirea informatiilor prezentate pe acel site. Mai mult decat atat, sa mai luam in calcul existenta unor aplicatii care periodic sincronizeaza preturile si stocurile produselor cu cele existente la furnizorii directi. Pentru a imbunatati imaginea de ansamblu sa consideram ca magazinul are cateva zeci de mii de produse. In cuvinte mult mai simple si mai tehnice: o multime de interogari sql de tip insert, update dar mai ales select.

Dezavantajul unui astfel de scenariu este evident cel al supraincarcarii bazei de date cu interogari care de cele mai multe ori se vor repeta si vor furniza acelasi set de date. Cu toate ca, de exemplu, MySQL detine un cache propriu din care returneaza un set de date al unei interogari la o repetare a acesteia, aplicatia PHP care interogheza baza de date va trebui sa realizeze tot protocolul de comunicare, sa furnizeze interogarea si sa primeasca datele, deci niste timpi desi mici, deloc de neglijat in contextul unui volum de trafic ridicat.

Continuand scenariul nostru de “groaza” mai trebuie luat in considerare faptul ca la o interogare de tip insert sau update, cele cauzate de aplicatia de administrare, pot aparea lock-uri pe campurile, inregistrarile sau chiar tabelele din baza de date, deci pana la terminarea executiei si scrierea ori modificarea cu succes a datelor in baza, o instructiune select, nu va putea citi baza de date pentru preluarea informatiilor si va fi pusa in asteptare pana la terminarea tranzactiei. Rezulta un timp mort si mai mare. Cache-ul ar trebui sa intervina in astfel de momente, cand putem spune ca majoritatea interogarilor vor furniza acelasi set de date pentru perioade definite de timp,  iar rularea lor nu ne-ar aduce decat dezavantaje.

Interogand baza de date pentru a obtine informatiile despre produsele din categoria “Monitoare LCD” vom obtine unset de date reprezentat printr-un vector cu produsele din acea categorie. Datele din acest vector pot fi introduse in cache. Conform algoritmului general descris mai sus putem scrie urmatorul cod PHP

if (!($data = loadFromCache('cache_for_category_id_' . $categoryId)))
{
$data = loadDataFromDatabase($categoryId);
saveToCache('cache_for_category_id_' . $categoryId, $data, 3600);
}

Plecam astfel de la premisa ca informatia cautata se afla in cache si chiar incercam sa o preluam. Daca functia loadFromCache() va intoarce o valoare nula atunci inseamna ca datele nu se afla in cache si ele vor trebui aduse din baza de date, lucru ce se va face prin functia loadDataFromDatabase() iar apoi salvate in cache cu ajutorul functiei saveToCache(), cache valabil o ora. Chiar daca presupunerea noastra initiala referitoare la existenta datelor in cache este adevarata sau nu, dupa executarea acestei portiuni de cod vom avea in variabila $data informatiile necesare.

Trebuie avut in vedere faptul ca in tot acest timp datele considerate valide sunt cele din baza de date, cache-ul fiind doar o copie locala a acesteia. Desi sistemul ne va reseta automat cache-ul dupa expirarea perioadei de viata, vor exista situatii cand cache-ul va deveni inconsistent, adica nu va mai reflecta realitatea din baza de date. Deci, la adaugarea unui produs nou in baza de date in categoria “Monitoare LCD”, cache-ul construit mai devreme nu mai este consistent(nu contine si acest nou produs). Cum varianta in care asteptam trecerea celor 3600 de secunde pentru a se recrea cache-ul nu ne multumeste(perioada putand fi mult mai mare), aplicatia de administrare va trebui sa intervina asupra cache-ului si sa invalideze inregistrarea ce contine datele din aceasta categorie. In acest mod vom forta recreerea cache-ului cu noile informatii la urmatoarea accesare a categoriei respective.

resetCache('cache_for_category_id_' . $categoryId);

In tot scenariul de mai sus am considerat crearea de cache-uri pe categorii si nu unul global care sa contina toate categoriile existente pe site, din considerente de acces si de resetare. Este mai simplu sa alegem direct cache-ul categoriei pe care dorim sa o afisam decat sa incarcam toate categoriile prin care sa o cautam pe cea dorita, precum este mai normal ca la introducerea produsului nou in categorie sa resetam doar cache-ul categoriei respective si nu cel al tuturor produselor.

Unelte

PHP nu detine nativ functii de lucru cu cache-ul, insa exista extensii PECL care pot fi instalate si cu care se pot lucra, printre care enumeram Memcache si APC.

Folosirea extensiei Memcache:

$cache = new Memcache();
$cache->addServer('localhost');
if(!($data = $cache->get('cache_id'))
{
$data = getData();
$cache->add('cache_id', $data);
}
$cache->delete('cache_id');

Folosirea extensiei APC:

if(!($data = apc_fetch('cache_id'))
{
$data = getData();
apc_add('cache_id', $data);
}
apc_delete('cache_id');

Diferenta dintre cele 2 extensii este aceea ca Memcache va stoca informatiile in memoria RAM a serverului, pe cand APC le va stoca in fisiere pe hard disc.

A Practical Guide to Data Caching with Zend Server scrisa de Shahar Evron, Product Manager la Zend Technologies, Inc., este o lucrare pe care o recomandam celor interesati de acest subiect.