On 27/08/2011 16:10, Olivier Bonvalet wrote:
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.
J'ai failli oublier : pour ma part je ne conseillerais pas SPIP. Entre les accès disque et le code indébuggable (eval()...), ça a vraiment été galère avant d'arriver à quelque chose d'à peut-prêt scalable.
Il parait que ça s'est amélioré coté disque dans les dernières versions, mais le système de cache + le système de sessions interne malmenaient pas mal le filer, ce qui réduit pas mal les possibilités de "clustering". Du coup on a tout remplacé par une énorme VM redondée (Xen/DRBD).