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>

<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

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

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.
 
<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
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
</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
 
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.
 
(Nota: Nu avem nevoie inca de memcached pentru ca nu folosim decat un singur server.)