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: frsag-bounces@frsag.org on behalf of Mathieu Goessens Sent: Tue 06/09/2011 07:26 To: frsag@frsag.org 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 gebura@poolp.org 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 ?