* -Luat stampila de la Sergiu-
* -Mers la banca sa punem bani pe card-
* -'Code review':http://reviewboard.infoarena.ro la toate change-urile de pana acum-

* svn up pe live

* svn up pe live
 
h2. Performanta site-ului
 
(Cristian: las mai jos niste notite despre cum ar putea fi imbunatatita performanta site-ului. Nu sunt informatii 100% verificate, luati-le ca puncte de plecare in investigatiile pe care le faceti.)
 
h3. MySQL
 
MySQL, asa cum il folosim noi, este suspectul principal. De fiecare data cand site-ul nu raspunde si am putut sa ma uit la lista de procese MySQL era in top. Chiar si cand site-ul este responsive si fara trafic semnificativ, MySQL consuma constant CPU. Spre exemplu, acum e 5 dimineata in Romania, site-ul este responsive, iar primele doua procese arata asa:
 
<pre>
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1179 mysql     15   0  175m  44m 3072 S   84  4.3  60370:09 mysqld
19234 apache    17   0 75336  24m  10m S    8  2.4   0:03.17 httpd
</pre>
 
Unele query-uri sunt prea incete. In /var/lib/mysql/infoarena-slow.log gasiti un slow-queries log facut de MySQL. (Are 1.4GB!) Log-ul trebuie interpretat cu atentie deoarece unele query-uri incete pot declansa o cascada de alte query-uri incete. Un query care in mod obisnuit este foarte rapid poate sa se blocheze asteptand un alt query sa termine; ambele query-uri ajung in infoarena-slow.log.
 
Din ce am observat eu mai demult, printre cele mai incete query-uri se numara cel pentru monitorul de evaluare, mai ales pe masura ce avansezi la pagina 2, 3, 4, etc.
 
Daca vedeti un query incet, sansele sunt ca sa poata fi optimizat. Folositi EXPLAIN (SQL) ca sa vedeti daca facem uz de indecsi, incercat sa reformulati JOIN-uri cu subqueries (WHERE X = (SELECT ... )), si, daca trebuie, faceti cache la tabele.
 
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.
 
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.