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 orienté site de contenu (CMS) :
La réponse la plus efficace est toujours dans une bonne gestion du (des) caches. 1) il n'y a pas plus rapide qu'une requête qui n'est pas faite (réduire les requêtes pour afficher une page, utiliser le cache du navigateur) 2) Il est très rare qu'un donnée doive être recalculée à chaque requête (une page valide 2min me parait convenable, utiliser un cache de page comme varnish et des entêtes HTTP correctes, des cas particuliers comme les commentaires peuvent être traités à part en asynchrone) 3) lorsqu'on construit la page, tout ne doit pas systématiquement provenir d'une base de donnée, le point généralement le plus faible au niveau perfs. utiliser là aussi des caches comme APC (local à une machine), memcache (commun), des systèmes noSQL (redis...)
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.
[...]
Où passe du temps l'appli ? varnish, apache, base de données ? Il faut d'abord bien cerner le problème pour ensuite agir au bon endroit.
En cas de pic insurmontable, pourquoi est-ce-que ce n'est pas uniquement varnish qui répond, avec des durée d'expiration du cache positionnées assez haute, pour qu'un même client ne revienne pas trop vite. Évidement, si le site doit réellement envoyer des informations différentes à une fréquence élever, il y a des limites, mais calculables.