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