On 07/09/2011 20:08, Rémy Sanchez wrote:
On Monday 05 September 2011 12:24:11 Jean Baptiste Favre wrote:
Identifie les goulots d'étranglement dans le code (grâce à Pinba par exemple, y en a sûrement) et fais-les corriger.
Pour rentrer plus dans le code, le combo xdebug/kcachegrind est très sympa aussi.
<raconte sa vie> De mon côté, j'ai sauvé un serveur de la noyade en implémentant la gestion du cache 304 pour les clients. En gros, on avait chaque client qui faisait un poll sur une table de 100000 entrées toutes les 5 secondes (plus d'autres trucs... On dépassait la requête par seconde par client).
L'astuce était simple : à chaque fois que quelqu'un affiche une page, on ajoute l'URL et le numéro de session dans une table MySQL de type MEMORY. Comme ça, la prochaine fois qu'il demande la même page, on lui sert un 304 avant même d'avoir chargé tous les fichiers PHP etc. La technique après c'est bien sûr que quand on reçoit une requête en POST, on vide la table, comme ça on re-génère toutes les URL.
Bon dans mon contexte c'était une appli avec peu d'utilisateurs et du contenu qui change relativement peu souvent, donc ça a super bien marché (on a divisé la charge par 10). </raconte sa vie>
My 2 bitcoins,
C'est probablement un résumé rapide, mais de manière générale si l'idée est de balancer un 304 quasi systématique durant les N prochaines secondes, l'idéal est encore d'envoyer un joli entête expires d'une trentaine de seconde. La requête HTTP sera encore plus rapide, vu qu'elle ne se fera pas.