Bonjour, en lisant votre problématique, je trouve que ce que vous exposé reste est encore trop vague. Pour être efficace, mon expérience m'a indiqué qu'il est nécessaire d'avoir entre autre un monitoring temps de réponse entre chaque éléments de votre architecture en particulier durant la monté en charge pour par exemple voir goulot d'étranglement et les temps de bascule.
Il existe à mon sens beaucoup de paramètres entrant en jeux dans l'optimisation d'une architecture d'accès. Des tunning kernel nottament de la stack TCP/IP, du nombre de handlers système, des timeout, (...) en passant par la politique de LB avec/sans persistance de session selon quel critère (quid des politiques), des caching opérés (politique de caching ? Edge Side Include, CDN), de la réécriture protocolaire (avec ou sans contenu), de la terminaison SSL, de la compression, de la gestion des chunk, de la sécurité et des blacklist, de l'indexation et/ou du partitionnement des bonne table dans la DB, du caching de requête ... En bref, une approche plus ciblée de votre probélmatique en précisant les bottleneck structurants et impactants pour vous et qui vous sont préjudiciable sont "sine qua non" pour optimiser au mieux votre architecture. Par exemple avez-vous pensez à bien tuner vos worker (max, min et spare) Apache en fonction de vos access log et autres stats ? Mon expérience m'a également appris que les éléments d'architecture les plus en amont de la chaine d'accès doivent implémenter des sockets event pour scaler correctement face au model multi-thread/multi-proc nettement moins performant avec la montée en charge. Ceci passe en général par un vrai projet de fiaibilisation avec des actions plus ou moins prioritaire selon vos besoins et votre budget dans pas mal de cas et ne peut à mon avis être rapidement élucidé à moins d'un véritable SPOF dans votre archi/conf ce qu'un monitoring fin des temps de réponse/code de retour ne mettra pas longtemps à mettre en évidence ;-) HTH. Cordialement, J.M. Le 6 septembre 2011 11:16, Francois Romieu <rom...@fr.zoreil.com> a écrit : > Bonjour, > > Gregory Duchatelet <greg-fr...@duchatelet.net> : > [...] > > 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 premier cas impose une copie kernel <-> userspace pour la mise en > cache et une autre à chaque restitution. Suivant que la mise en oeuvre > est ou non naïve, ça risque d'impliquer de vraies copies bien lourdes > (et pas juste des acrobaties de mmap). > > Apparemment nginx effectue un sendfile sans passage des données par > l'espace utilisateur. Pour peu qu'on se décharge du calcul des sommes > de contrôle IP sur le matériel, ça devient *très* économique pour des > données cachées. > > J'ai bon ? > > -- > Ueimor > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
