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/