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-fr...@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 <in...@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/ > >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
