On 27/08/2011 14:39, Pierre-Henry Muller wrote:
Le 27/08/11 12:53, Benjamin Billon a écrit :
Je repose une autre question, quand un client veut faire un site forte charge à partir d'un CMS ou moteur de blog du marché et que ces derniers n'ont pas d'intelligence dans la répartition de charge quel type de solution autre que mysql proxy vous utiliseriez?
T'as un exemple concret ? Assez rapidement, les caches (mysql et http) font le plus gros du boulot pour soulager les requêtes de lecture, surtout pour du CMS/blog "bateau". S'il devient nécessaire d'optimiser le cache et qu'il est envisageable de taper dans le code, memcached est une solution qui a fait ses preuves.
Des exemples concrets j'en ai mais je ne pourrais pas les citer.
Il faut imaginer un site fait sous Drupal ou Wordpress par ex, 50 contributeurs pratiquement en simultanés tous les jours donc les caches seront souvent vidés, des stats élevées on est dans une fourchette entre 1 et 2 millions de pages vues / jour. Le serveur sql actuel est une super grosse machine bien gavée mais pas du tout redondée et elle souffre vraiment malgrès un raid 10 de ssd, des cpus, de la ram à foison. Pour savoir si les caches suffiraient sans contributions, j'ai demandé une période de plusieurs heures un we sans aucune contribution, le nombre de requête diminue, le serveur respire mais sans plus. En consultation pure on est à ~75% read 25% write. La nouvelle architecture doit répondre à l'ouverture du site dans plusieurs nouvelles langues, public visé prévu x 3 d'ici à 1 an et demi, il faut donc augmenter la capacité de lecture.
la nouvelle archi faite :
- plusieurs front web, apc opcode
- plusieurs proxy pour les statics
- des srv memcache avec 2 instances memcached pour séparer les sessions
et le cache de l'appli
- 2 mysql en réplication master/master avec une vip sur l'un pour les
requêtes write, l'autre n'est qu'un hot standby
- des mysql en slave pour la lecture et un pour les backups
L'application que le client fait développer ne comporte pas de mécanisme pour faire du split des requêtes, les développeurs ont dit que c'était compliqué et que ça couterait cher à développer, du coup c'est au niveau système qu'il faut trouver une solution. Sachant que le serveur le plus costaud ne suffira pas à tenir la charge sql et qu'après une consultation mysql cluster n'est pas adapté à ce type de base et de vue, la réplication est donc la seule possibilité pour augmenter les capacités.
J'ai donc ajouté 2 mysql-proxy HA en rw split en étant conscient du problème potentiel du last insert id par ex, chose que j'ai remonté aux dev et au client mais ça ne les empêche pas de dormir.
Bref dans des cas comme celui là où la logique voudrait que cela soit fait au niveau du code et non au niveau du système il n'y a pas de solutions autre que celle là à mon sens, je suis néanmoins preneur d'autres solutions si ça existe.
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