Nu aveti permisiuni pentru a descarca fisierul grader_test17.ok
Inverseaza reviziile

Diferente pentru planificare/camp-alcatraz intre reviziile #31 si #27

Diferente intre #26 si #27

Nu exista diferente intre titluri.

Diferente intre continut:

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.

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.

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

Nu exista diferente intre securitate.

Topicul de forum nu a fost schimbat.