h3. Ziua 1 (2008-11-15)

* Workflow and tools: 'Trac':http://hackers.devnet.ro and 'Review Board':http://reviewboard.infoarena.ro
* Explicat 'MVC':http://en.wikipedia.org/wiki/Model-view-controller si 'unit testing':http://en.wikipedia.org/wiki/Unit_testing
* Toata lumea face 'setup':http://hackers.devnet.ro/wiki/HackingTutorial la infoarena
* Citim si actualizam 'wiki-ul':http://hackers.devnet.ro/wiki

* Workflow and tools: 'Trac':http://hackers.devnet.ro and 'Review Board':http://reviewboard.infoarena.ro ✓
* Explicat 'MVC':http://en.wikipedia.org/wiki/Model-view-controller si 'unit testing':http://en.wikipedia.org/wiki/Unit_testing ✓
* Toata lumea face 'setup':http://hackers.devnet.ro/wiki/HackingTutorial la infoarena ✓
* Citim si actualizam 'wiki-ul':http://hackers.devnet.ro/wiki ✓

* Rulat 'YSlow!':http://developer.yahoo.com/yslow/ si citit tutoriale ('1':http://developer.yahoo.com/performance/rules.html, '2':http://www.thinkvitamin.com/features/webapps/serving-javascript-fast)

* Reorganizat 'tichete':http://hackers.devnet.ro/report/3 pentru 2.2

* Reorganizat 'tichete':http://hackers.devnet.ro/report/3 pentru 2.2 ✓

** 'Notite la tichete':camp-alcatraz/tichete-2.2

* Lucram la identificarea bottleneck-urilor si rezolvarea lor ('benchmarks':http://hackers.devnet.ro/wiki/Benchmarks)
* Backup script

* Lucram la identificarea bottleneck-urilor si rezolvarea lor ('benchmarks':http://hackers.devnet.ro/wiki/Benchmarks) ✓
* Backup script ✓

h3. Ziua 2 (2008-11-16)
* Raport despre imbunatatirile de performanta

* Implementam alte feature-uri
* Stabilim data si obiectivele pentru urmatorul Coding Camp

* Implementam alte feature-uri ✓
* Stabilim data si obiectivele pentru urmatorul Coding Camp ✓

* Feedback
h2. To Do

* -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

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 style="line-height: 1em">

==code(c)|

  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.

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">

==code(c)|

# 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
39114    1.7286          /home/infoarena/live/cache

348      0.0028          /tmp
1194     0.1031          /usr/bin
309      0.3081          /usr/lib

</pre>

==

Prima coloana reprezinta numarul de fisiere dintr-un director, a doua reprezinta timpul de acces (fopen + fread 2KB) la 100 de fisiere alese aleator din acel director. Script-ul fs-benchmark il gasiti pe live.
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.)