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:

==code(c)|

<pre style="line-height: 1em">

  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.

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.

==code(c)|

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