Coding Camp Alcatraz

Ne intalnim in weekend-ul 15-16 noiembrie 2008 la Hostway Romania
Prima zi incepe la ora 10:00 la statia de metrou Nicolae Grigorescu.

Locatie

Str. Theodor Pallady, nr. 26, Sector 3, Bucuresti - intersectia cu Str. Mizil, in spatele Liceului de Chimie. 
Vezi harta pe Salut Bucuresti sau pe Yahoo

Un mod de a ajunge acolo este sa coborati din metrou la statia Nicolae Grigorescu si sa luati orice tramvai in directia corecta (adica opusa Dristor) pentru 3 statii. In statia in care trebuie sa coborati veti vedea Liceul de Chimie.

Avem la dispozitie sala, whiteboard, proiector, internet.

Detalii

  • Fiecare participant trebuie sa vina cu un calculator cu Linux (preferabil Ubuntu) instalat pe el
  • Asociatia infoarena asigura masa, bautura, snacks-uri

Participanti

Specifica cand poti veni si cat poti sta.

...

Plan

Ziua 1 (2008-11-15)

Ziua 2 (2008-11-16)

  • Raport despre imbunatatirile de performanta
  • Implementam alte feature-uri ✓
  • Stabilim data si obiectivele pentru urmatorul Coding Camp ✓
  • Feedback

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

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

Benchmarks

Folositi ./scripts/benchmark pentru masuratori. Cel mai probabil trebuie imbunatatit putin. (Nu face decat sa ruleze apache-benchmark pe o serie de URL-uri.) Experimentati cu flag-ul -c pentru request-uri concurente.

Benchmark-urile trebuie interpretate cu atentie. Configuratia live este diferita de cea pentru development.

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:

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

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.

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.

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

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.

# 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
28773    1.2640          /home/infoarena/live/attach
10       0.0021          /home/infoarena/live/www
45       0.0031          /home/infoarena/live/www/views
102972   1.8296          /var/lib/php/session
348      0.0028          /tmp
1194     0.1031          /usr/bin
309      0.3081          /usr/lib

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

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.

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