Le 6 sept. 2011 à 07:26, Mathieu Goessens gebura@poolp.org a écrit :
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 ?
Idem: diminuer la latence sur les statiques les plus sollicités (surtout si il y a xTo de statique stocké sur du stockage "lent").
Yacine kheddache / www.alyseo.com