HAProxy ne se justifie pas! HAProxy est amour pour les sites à fort traffic ou à forts pics. Si Chuck Norris était un load-balancer, il serait HAProxy. Je dirais même plus, "What else?"
Baptiste
2014-01-30 Alexandre infos@opendoc.net:
Conclusion de tout ca, on a recyclé un max de machines pour bouffer la charge. Mais un projet de construction d'un deuxième site est lancé, pour faire de l'actif/actif. J'aimerais bien avec de l'HAProxy '') mais il faut le justifier.
Alex.
On 23/01/14 07:10, Baptiste wrote:
Salut Alexandre,
Un HAProxy avec son maxconn et sa gestion de file d'attente + TCP buffering embedded et voilà :) Tu peux en placer pleins entre toutes tes couches applicatives, et tu vas protéger tes applications durant les pics. On peut t'aider si tu veux ;)
Baptiste
2014/1/22 Xavier Beaudouin kiwi@oav.net:
Hello,
On 21/01/14 12:56, Yohann QUINTON wrote:
De combien de millier/million de requête secondes parlons nous lorsque ça décroche ?
D'après les infos du "ipvsadm", en statue "connecté" ca commence à décrocher vers les 60 000.
Tu as une limite de sockets a 65535 ports dispo sur une ip. En mettre plusieurs en // peut déjà passer ce cap.
Après être un poil agressif sur le timeout TCP peut être utile... Selon l'os...
Est-ce que tu as des stats aux niveaux de tes différents daemon / serveurs ?
Qu'est ce qui ralenti le tout ? lighttpd / nginx / php / bdd ?
Il n'y a pas de MySql process list important, ce qui bouffe c'est php-cgi.
Y a que moi ou je suis le seul a voir ce qui hurle... php-cgi ... Pourquoi pas php-fpm ?
On peux faire de bonnes choses avec non ?
Xavier
Liste de diffusion du FRsAG http://www.frsag.org/