Pour ce qui est de la BDD, je ne suis pas totalement d'accord :
- une bonne BDD est une BDD qui est maitrisée en interne. Si tu n'as pas de connaissance en Postgresql (ou de mec capable de monter rapidement en compétence dessus, ou les moyens de faire bosser un DBA compétent externe), ce n'est pas forcément une bonne idée de passer de MySQL à Postgresql.
- une appli moisie reste une appli moisie, quelle que soit la BDD. Refondre l'appli ou optimiser l'appli représente toujours les 90 premiers % du gains de perfs.
Les problèmes de perfs de MySQL deviennent franchement problématiques à partir de trafics bien plus importants que 20k visites/j (sur une appli standard), et restent la plupart du temps contournables avec des dévs compétents (après tout, Facebook continue à largement tourner sur du MySQL).
A l'opposé, avec des devs pas à niveau et un bon DBA, Postgresql est plus que recommandé.
Sinon :
Vu ce niveau de trafic, un load-balancer semble être un bon principe, avec 2 serveurs pour le web (voire 2 frontaux + 2 BDD, avec, dans le cas de MySQL, de la réplication), et avoir un/des serveur(s) séparé(s) pour le métier (avec des mécanismes/procédures pour être capable de reprendre le métier sur la plateforme web).
Si le site est assez statique, le meilleur moyen de gagner des perfs est encore de mettre en place un proxy cache (ex: varnish) : les meilleurs perfs sont celles obtenues quand on ne tape pas dans PHP ou dans la base de données.
Suivant la manière dont tu accèdes aux données, un cache applicatif peut aussi être utile (ex: memcached, redis) pour éviter des accès en base.
NB : à ce niveau de trafic, en PHP, ne stocke pas les sessions en BDD, mais dans memcached ou redis.
Si tu cherches un petit hébergeur compétent en mode infogéré, tu peux contacter Typhon.
JFB
Le 27 nov. 2012 à 09:28, Sylvain Donnet a écrit :
C’est difficile de conseiller à ce stade « ya ka faire ci … », mais effectivement la virtualisation est une bonne approche car elle permet de monter en puissance plus facilement qu’avec du matos à chaque fois. Je reste sur le fait que 20K voulait bien dire 20000 visiteurs jours.
Les technos citées (Ngix, ...) sont « balançables » (HA-Proxy ou autre, …) , à la condition que l’appli PHP le supporte (problème des sessions, …). Pour la base de données, nous, on recommande aussi Postgresql, en lieu et place de Mysql quand c’est possible.
Maintenant, ne jamais oublier qu’une appli pourrie ne sera jamais compensée par du hardware. Combien de fois j’ai vu des applis où 1 ligne de code (UNE) fout en l’air les performances : requête SQL avec jointures mal faites, boucles PHP à ne plus savoir où on est,…
De : frsag-bounces@frsag.org [mailto:frsag-bounces@frsag.org] De la part de SD76
Envoyé : mardi 27 novembre 2012 00:34
À : French SysAdmin Group
Objet : [FRsAG] Conseil sur une architecture serveurs
Bonjour,
Étant sysadmin junior, je me permet de vous sollicitez afin de faire les bon choix.
Contexte:
PME immobilière nationale en fort développement. Actuellement site vitrine et outils métiers
ne font qu'un même techno (Apache/php/mysql) et serveur unique...
On a pas mal de souci de perf (code non optimisé et pareil coté BDD).
20k visiteurs unique jours / 80 salariés.
Les volumétries sont raisonnable.
Objectif:
Tout est en cours de refonte (Nginx/PHP/PostGresql), nous souhaitons isoler le site et l'application métier sans trop arriver à choisir. Améliorer la disponibilité, faciliter la mise en prod…
Exemple d'archi:
Site et sa base de donnée sur un premier serveur avec un failover
idem pour la partie métier
Site et appli métier sur un même serveur et chaque base de donnée sur leur serveur…
Les combinaisons sont nombreuse…
Virtualisation ou non? Les techno nous importe peu tant qu'elles on fait leurs preuve.
Étant donné la croissance de l’activité, nous recherchons aussi la scalabilité.
L'idée étant de garder au maximum la main sur les machines, le "cloud" ne nous
botte pas vraiment.
Et pour avoir déjà donné, je ne veux pas de solution à base de bidouillage :)
Si vous avez des retours d’expériences sur des besoins similaire ou des remarques à apporter
j'en serait ravi.
NB: O*H nous hébergent actuellement, je souhaiterai déménager. Si vous avec de bon contact,
je suis preneur.
Merci.
sd
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/