On 27/08/2011 15:00, Pierre-Henry Muller wrote:
Le 27/08/11 14:55, Olivier Bonvalet a écrit :
Bonjour,
pour un cas plus ou moins similaire (SPIP et trafic similaire), on a
mis en place deux choses :
- varnish en front pour réduire très fortement le boulot de SPIP
- ajout/modification de nombreux indexes dans la BDD, ceux par défaut
n'étant pas adaptés (à l'époque en tous cas)
- ajout de quelques vues réduisant le volume de données à analyser
Si ça peut aider...
Quant à Drupal& Wordpress, je ne saurais dire, jamais administré à ce
régime.
Olivier
Bonjour,
Le cache html est géré par l'application sur les memcaches mais le
nombre de contribution et les commentaires
va forcément faire descendre le ratio hit de ces éléments. C'est un
élément que je n'ai plus mettre en application ici.
Pour les index, Drupal était en myisam par défaut on l'a passé en
innodb, les index semblent bon pas de requêtes lentes ou autre
simplement un nombre conséquent. Pour les vues on en a parlé au dev de
trouver le top100 des requêtes les plus courantes qu'on pourrait passer
avec une vue mais ca ne s'est pas fait.
Sur ton exemple de spip tu avais des parties html en cache sur le
varnish, sans ca donnait quoi à cette charge là. C'est pour me faire une
idée de ce cms que je connais mal.
Pour moi l'intérêt n'était pas vraiment de "mettre en cache du html", mais
d'éviter très fortement les appels à Apache/PHP.
Par contre effectivement, on a pas de commentaires à gérer. Mais tant qu'on ne
demande pas du temps réel, un cache d'une minute aide déjà bien.
Actuellement configuré sur 1 minute, ce cache a un ratio moyen de 95% pour 200
req/s (il ne gère pas les images, seulement html/css/js).
Les contributeurs de leurs cotés sont identifiés, et sont totalement exclus du
cache Varnish.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
