h3. Caching

Daca trebuie, putem sa bagam in cache intreg tabelul de utilizatori, probleme, runde, si poate altele. Asta ar optimiza semnificativ unele query-uri. Spre exemplu, in monitorul de evaluare nu ar mai trebui sa facem JOIN la tabelele de task-uri, runde, si utilizatori pentru a afisa titluri si nume. SELECT-am doar id-uri si restul informatiile le scoatem din cache.

Daca trebuie, putem sa bagam in cache intreg tabelul de utilizatori, probleme, runde, si poate altele. Asta ar optimiza semnificativ unele query-uri. Spre exemplu, in monitorul de evaluare nu ar mai trebui sa facem JOIN la tabelele de task-uri, runde, si utilizatori pentru a afisa titluri si nume. SELECT-am doar id-uri iar restul informatiilor le scoatem din cache.

Caching-ul poate sa rezolve multe probleme de performanta insa are dezavantaje importante:
* Complica codul. Cand actualizezi X in baza de date trebuie sa invalidezi X din cache impreuna cu toate informatiile care au fost calculate pe baza lui X.

* Serializarea si deserializarea nu sunt operatii teribil de rapide. Nu cred ca e eficient sa faci 'apc_fetch':http://www.php.net/manual/en/ref.apc.php la un array cu intreaga lista de utilizatori. Cache-ul trebuie spart pe bucatele mici. E rapid sa faci fetch la un element insa probabil nu-ti permiti sa iterezi prin multe elemente.

* Serializarea si deserializarea nu sunt operatii teribil de rapide. Nu e eficient sa faci 'apc_fetch':http://www.php.net/manual/en/ref.apc.php la un array cu intreaga lista de utilizatori. Cache-ul trebuie spart pe bucatele mici. E rapid sa faci fetch la un element insa probabil nu-ti permiti sa iterezi prin multe elemente.

h3. Directoare mari si plate

Am observat ca pe sistemul de fisiere de pe live (ext3), timpul de acces la un fisier oarecare dintr-un director variaza foarte mult in functie de numarul total de fisiere din acel director.

Am observat ca pe live (FS ext3), timpul de acces la un fisier oarecare dintr-un director variaza foarte mult in functie de numarul total de fisiere din acel director.

<pre style="line-height: 1em; overflow: auto">
# echo -n ~infoarena/live/{cache,attach,www,www/views} /var/lib/php/session /tmp /usr/bin /usr/lib | xargs -d" " -IX echo ' echo -e `find X -type f -maxdepth 1 | wc -l` "\t" `~infoarena/live/scripts/fs-benchmark X` "\t" X ' | bash

Eu doar am observat ca timpul de acces variaza semnificativ insa _nu stiu daca si cum ne afecteaza pe noi_. Incarcarea unei pagini de 'clasament':clasament-arhiva fara cache in browser poate sa genereze usor 50 de request-uri HTTP. Daca la fiecare request accesam un fisier de sesiune (din /var/lib/php/session) si inca un fisier din cache sau din attach, ajungem la 100 de accesari de fisiere.

Probabil ca din acelasi motiv, 'MediaWiki stocheaza fisiere de cache in directoare "stufoase."':http://www.mediawiki.org/wiki/Manual:File_cache

Probabil ca din acelasi motiv 'MediaWiki stocheaza fisiere de cache in directoare "stufoase."':http://www.mediawiki.org/wiki/Manual:File_cache

h3. Sesiuni in memorie

infoarena foloseste momentan sistemul de sesiuni implicit configurat in PHP, adica multe fisiere (~100k) in /var/lib/php/session. Sistemul de sesiuni din PHP suporta customizarea backend-ului de stocare. Se poate cupla usor APC. Dezavantaj: cand restartam Apache pe live se pierd toate sesiunile.

infoarena foloseste momentan sistemul de sesiuni implicit configurat in PHP, adica multe fisiere (~100k) in /var/lib/php/session. Sistemul de sesiuni din PHP suporta customizarea backend-ului de stocare. Se poate cupla usor APC. Dezavantaj: cand repornim Apache pierdem toate sesiunile.

(Nota: Nu avem nevoie inca de memcached pentru ca nu folosim decat un singur server.)

(:P Nota pentru Mircea: Nu ne trebuie memached, avem un singur server.)