Le 06/09/11 08:58, Gregory Duchatelet a écrit : > Le 06/09/2011 07:43, Yacine Kheddache a écrit : >> >> 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"). >> >> > > Je rejoins Mathieu : quelles sont les différences entre un reverse > proxy qui va récupérer ses pages sur un frontal de statiques qui va > lui même les récupérer sur un disque, puis stocker le tout en mémoire; > et un serveur statique type nginx qui va directement récupérer les > pages sur disque, qui seront mise en cache par le buffer cache de Linux ? > Le buffer cache de linux ne fait pas des miracles et les accès disques restent toujours assez élevés. Si tes proxy ont accès au FS qui contient les données effectivement il peut être intéressant de sauter un intermédiaire. Par contre je suis plutôt pour le fait que les proxy se constitue un cache en local sur un média lent et mettent en memcache les éléments les plus demandé.
La raison est simple, cas réel, grosse plateforme web multi langues qui pousse H24 à débit constant sans l'effet de vague horaires qui nous permet de faire des maintenances. La plateforme fait une migration, cold restart pour les mysql, les web. Si tous les proxy du client à travers le monde (Asie, Europe, USA) avaient du retransférer les données depuis les serveurs front ou directement le FS partagé la plateforme ne serait jamais repartie. En ayant en cache disque local pratiquement tous les statics, les proxy ont été opérationnels immédiatement. La plateforme en cold restart a déjà bien souffert derrière autant ne pas lui rajouter de la charge inutile.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
