En premier lieu, un grand merci à tous pour votre précieux retour dexpérience dont je ferai (jespère) bon usage.
Concernant la question "Quel serait lintérêt de mettre un reverse proxy / cache devant mes serveurs de statics" : J'y vois plusieurs intérêt : 1) Soulager mon haproxy qui est en l'état le seul point d'accès de mon architecture et qui voit donc passer le traffic des serveurs d'applis + le traffic média. Je voudrais donc dédier un serveur pour y mettre varnish. Le cache me permettrait (selon mes benchs) de réduire le temps de réponse en supprimant la majorité des requête vers mes backends statics. Cela s'explique en grande partie car ce serveur cache sera en frontal. En l'état quand j'ai testé avec un varnish en local sur mes serveurs statics le gain était nul voir négatif. 2) Selon les résultats en prod je devrais pouvoir supprimer certains de mes serveurs loués statics chez OVH étant donné qu'il seront moins sollicités grâce au cache. Après, n'étant pas un gourou des architectures Web, je suis ouvert à toute suggestion ou questionnement.. Pour la suite, je pense donc m'orienter dans un premier temps vers une solution de bench HALOG + PIMBA pour tirer les conclusions qui s'imposent quand aux bottlenecks. Merci encore Vincent -----Original Message----- From: [email protected] on behalf of Mathieu Goessens Sent: Tue 06/09/2011 07:26 To: [email protected] Subject: Re: [FRsAG] Optimisation architecture Web / Retour d'experience ? On 06/09/2011 07:09, Yacine Kheddache wrote: > > Le 6 sept. 2011 à 06:40, Mathieu Goessens <[email protected]> a écrit : > >> On 05/09/2011 11:37, vincent finet wrote: >>> Effectivement tu as raison une partie de la réponse passe indéniablement >>> par ab / firebug. >>> >>> C'est ce que j'avais commencé à faire et qui tendait à confirmer qu'un >>> cache au niveau du reverse proxy permettrait déja de gagner de la perf au >>> niveau du chargement des médias statiques. >> >> Heu, >> >> Il y a que moi que ça choque ? Garder en cache des fichiers statiques, >> je ne vois pas trop l'intérêt. Es tu sûr que cela serait réellement plus >> performant ? J'en doute... ou alors effectivement, il y a un problème. > > Au contraire, c'est même plutôt la base et le type de reverse proxy le plus > simple... > > Ça permet de décharger les frontaux de nombreuses requêtes (ils peuvent ainsi > se concentrer sur le dynamique...) et de fortement booster les temps de > réponses sur tout le contenu statique (css, images, videos...). > > Pour nous (reverse proxy et "CDN" maison pour nos clients), c'est : nginx et > ramfs a gogo avec du PCIe SSD pour certains besoins (volumes et budget plus > important...). > > PS: Il va de soit que le gain sera en rapport avec la performance du matériel > et du stockage utilisé sur les reverse proxy (ce qui explique nos choix > ci-dessus car les IOPS sont ici l'un des points clés). En l'occurrence ici On 05/09/2011 10:43, vincent finet wrote: > Mon architecture est en l'état la suivante : > > Un serveur frontal HAPROXY qui redirige les requêtes vers un pool de frontaux HTTP ainsi que vers un pool de media static. > Les frontaux HTTP sont des apaches / Les serveurs medias sont des lighttpd. Donc, ces fichiers sont déjà traités différemment ... Quel serait alors l'intérêt à mettre un reverse proxy devant et surtout de mettre du cache sur ces fichiers ? -- Mathieu Goessens IT consultant. [email protected] + 33 6 07 91 54 87 http://gebura.eu.org _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
<<winmail.dat>>
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
