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 bottleneck est le traitement PHP, et les
caches Memcache ne sont pas une solution. Les accès DB ne sont pas le bottleneck, right ?
bah non.... Si on reste dans le domaine de l'optimisation des perfs, du cache et d'un site qui répond mieux (sur la même machine), dans ce domaine, on retrouve souvent la phrase suivante (qui a déjà été largement évoqué lors de ce thread)...
"Performance tuning is art not science" ;)
Donc, globalement, il y a certaines "best practices" mais chaque cas est différent et va dépendre du site et de l'application...
Gérer un dimensionnement et la répartition de charge et les perfs qui vont avec, c'est une compétence à part entière qui nécessite des connaissances, de l'analyse, de la réflexion, et une solution adaptée à chaque cas malheureusement ...
Il n'existe pas de "apt-get install sitemarchemieux && /etc/init.d/sitemarchemieux start"... ;)
++
Le 22 janvier 2014 08:43, Greg greg-frsag@duchatelet.net a écrit :
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 plutôt du micro-framework voir pas de framework du tout. Phalcon ou HHVM sont des solutions alternatives, avec leurs avantages et inconvénients.
Des outils comme le profiler de Xdebug, NewRelic, Apps Dynamics, permettent d'identifier les bottlenecks au sein de l'app php.
Au niveau infra, migrer de CGI à FPM peut aider un peu. NGiNX a une fonctionnalité utile dans ce cas, où il maintient la connexion avec les processes PHP: fastcgi_keep_conn http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
Greg
Le 21 janvier 2014 21:51, Alexandre infos@opendoc.net a écrit :
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.
C'est noté.
Merci.
Cordialement,
Alexandre writes:
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 composée de serveurs apache + php5 + apc vers des serveurs lighttpd + php5-cgi + memcache. Cette migration partielle
nous
a permis de maitriser la charge des machines. Cependant, lors d'un évènement ponctuel, le trafic est si important que notre
infrastructure
est au maximum de sa puissance de calcul même après y avoir placé des revers proxy sous varnish. Le service est rendu mais lent. Nous
avons la
possibilité de désactiver des fonctionnalités à la volée pour
soulager
le traitement, mais cela reste une façon de contourner le problème.
Nous
avions pensé à "muscler" notre infra en y ajoutant plus de machines. Au-delà du prix, je me demande l'intérêt d'avoir une puissance de
calcul
aussi élevée pour 3 semaines max d'utilisation. J'ai donc pensé à des machines (type cloud) qui seraient préparées en amont et qui
pourraient
être activées sur demande (via une api ?) avec une facturation à l'utilisation.
Ce service doit surement exister chez amazon, gandi, ovh ...
L'avez-vous
déjà utilisé ? En êtes-vous satisfait ? Quelles sont les limites de
ce
service ? Avez-vous d'autres solutions qui seraient plus adaptées ?
Alexandre. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/