Bonjour,
Merci pour tous ces retours.
Je voulais rappeler que toute le code est en cours de refonte from scratch.
C'est justement à l'occasion de la migration que l'on souhaite passer sur un
hébergement plus fiable et plus scalable.
20K == 20 000 :D
Le souhait de quitter OVH est principalement leurs manque de sérieux sur des
interventions "programmé" (annoncé 5 min avant sur une mailing list) qui
plante une grande partie du réseau… ex: Y a un mois sur les switch; l'an
dernier sur les routeurs. Ma direction ne comprend pas, on à un serveur
vendu "haut de gamme".
J'avais augmenté les ressources hardware pour palier le problème de perf
le temps que les devs reprennent tout. Le code et l'archi de la DB etait
mal conçus. (turn over de dev, pas de doc, forte croissance de l'activitée...)
Bref.
HAproxy est une bonne solution, on à déjà regardé un peu mais comment éviter un
SPOF? seul l'hébergeur peut nous proposer du vrrp/carp (ou autre protocole
proprio). Comme la dit Tarik il y a bien heartbeat mais j'avais trouvé ca
un peut du bidouillage… Mais c'est plus moi que je vais remettre en cause ;)
On a moins regardé varnish on était plus partie sur du nginx pour le
cache. Pour le static nous avons prévus de le délocaliser au moins sur sur un
nom de domaine different et très facilement déplacable ailleurs.
Nayant pas de ferme de machine, la virtualisation me semble un peu démesuré
même site ça nous apporte plus de souplesse sur la scalabilité.
Le choix de postgresql à été fait par notre responsable technique qui maitrisse
cette techno. Et pour des modules tel que hstore ou PostGIS.
On est à 15hits/s. Pour les requetes SQL 46 req/s. Ces relevés ne sont pas trop
de bon indicateur étant donnée que tout va être refait et donc optimisé.
Au pire ca sera des valeurs max.
En tout cas j'y vois un peu plus clair je pense partir sur des machines
physique. Après j'hésite un peu sur mettre du LB dés maintenant ou voir comment
ca réagit avec un seul frontal…
sd