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 iar restul informatiilor 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 si restul informatiile 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 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 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.

h3. Directoare mari si plate

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.

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.

<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 repornim Apache pierdem 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 restartam Apache pe live se pierd toate sesiunile.

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

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