Je confirme qu'HAProxy fonctionne très bien :).
Et si vous n'avez pas lu, je conseille
http://www.alittlemag.com/effet-capital-m6-comment-tenir-la-charge/(évidemment,
YMMV).
Le 31 janvier 2014 15:49, Baptiste bed...@gmail.com a écrit :
HAProxy ne se justifie pas! HAProxy est amour pour les
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,
Le sujet initiale a été mis de coté par rapport à des questions de
performance Même optimiser au maximum, a un moment, le scaleout sera la
seul solution si la montée en charge est trop forte. L'idée de machine
prête à venir en soutien était intérressante...
donc si j'ai bien compris le
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
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
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer
la question :
Quelles sont les possibilités pour absorber les montées en charge
ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était
principalement
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal
parfois ça passe très mal ;-)
A part de proposer d'optimiser Encore tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching Level3, Akamai ou autres CDN (OVH pourquoi pas)...
Bien à toi
Bonjour Yohann,
On 21/01/14 12:48, Yohann QUINTON wrote:
Des retours sur ces plateformes, Les US et l'Irlande en terme de résal
parfois ça passe très mal ;-)
A part de proposer d'optimiser Encore tes traitements :
Cf par exemple : https://github.com/facebook/hhvm
Et rajouter du caching
De combien de millier/million de requête secondes parlons nous lorsque
ça décroche ?
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 ?
--
Yohann
Awedia
Le 21/01/14 12:50, Alexandre a écrit :
Bonjour
Le 21/01/2014 12:38, Alexandre a écrit :
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous
reposer la question :
Quelles sont les possibilités pour absorber les montées en charge
ponctuelles d'une infrastructure web ?
Hello,
Mon point de vu, en tout cas
Le 21 janv. 2014 à 12:45, seb astien krio...@gmail.com a écrit :
Hello,
Le 21 janvier 2014 12:38, Alexandre in...@opendoc.net a écrit :
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous reposer la
question :
Quelles sont les possibilités pour absorber
Hello,
On 21/01/2014 12:38, Alexandre wrote:
Quelles sont les possibilités pour absorber les montées en charge
ponctuelles d'une infrastructure web ?
Actuellement, nous migrons une partie de l'infra web qui était
principalement composée de serveurs apache + php5 + apc vers des
serveurs
On 2014-01-21 13:04, Frederic de Villamil wrote:
Le truc pénible : mon workflow de remplacement lors des mises à jour
n’est pas encore parfait. Hope it helps
Mon truc a 2 balles.
Ne pas mettre le code sur la machine.
Dans les scripts de demarrage, si /var/www/monsite/index.html n'existe
pas,
Le Tue, Jan 21, 2014 at 12:38:24PM +0100, Alexandre [in...@opendoc.net] a écrit:
Bonjour à tous,
c'est surement un sujet déjà abordé mais, je me permets de vous
reposer la question :
Quelles sont les possibilités pour absorber les montées en charge
ponctuelles d'une infrastructure web ?
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait
améliorer le temps de réponse du serveur web en front-end ?
autre chose, est-ce que délocaliser les contenus statiques types images
css, etc. sur un serveur FTP (après tout, c'est prévu pour...) ne
pourrait-il pas être plus
Le 21 janvier 2014 14:17, Pierre `Sn4kY` DOLIDON sn...@sn4ky.net a écrit :
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait améliorer
le temps de réponse du serveur web en front-end ?
Tu veux dire déporter le FPM sur un autre serveur et s'y connecter via un port ?
Intérêt limité,
Pour infos c'est une infra spécifique webservice qui ne renvoie que du
json. Cependant pour envoyer la donnée, il y a beaucoup d'url unique. Le
double niveau de cache est peu efficace. Pour ce qui est statique c'est
un traitement à part.
Alexandre.
On 21/01/14 13:02, Gilles Mocellin wrote:
Le 21 janvier 2014 14:17, Pierre `Sn4kY` DOLIDON sn...@sn4ky.net a écrit :
j'ai jamais testé, mais est-ce qu'un php-fpm en backend pourrait améliorer
le temps de réponse du serveur web en front-end ?
autre chose, est-ce que délocaliser les contenus statiques types images
css, etc. sur un
Bonjour Alexandre,
Pourquoi as tu arreté akamai ?
Si tu as du contenu statique cachable, je peux te proposer un solution CDN à la
demande
à prix compétitif, utilisable que dans ta période de pointe.
Je travaille avec les principaux CDN.
Cordialement,
Alexandre writes:
Bonjour à tous,
Le 21/01/2014 14:17, Pierre `Sn4kY` DOLIDON a écrit :
[...]
autre chose, est-ce que délocaliser les contenus statiques types
images css, etc. sur un serveur FTP (après tout, c'est prévu pour...)
ne pourrait-il pas être plus efficace également ?
[...]
Le protocole FTP nécessite une phase de
On 21/01/14 15:11, Damien Wetzel wrote:
Bonjour Alexandre,
Pourquoi as tu arreté akamai ?
J'ai dit ca ?
Si tu as du contenu statique cachable, je peux te proposer un solution CDN à la
demande
à prix compétitif, utilisable que dans ta période de pointe.
Je travaille avec les principaux CDN.
Bonjour,
donc si j'ai bien compris le bottleneck est le traitement PHP, et les
caches Memcache ne sont pas une solution. Les accès DB ne sont pas le
bottleneck, right ?
Si c'est le cas, à mon avis il faut faire maigrir l'application. Ne pas
utiliser de framework lourd type Symfony ou ZF, mais
22 matches
Mail list logo
