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.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
