Hello Antoine, Excerpts from Dominique Rousseau's message of 2013-01-21 16:14:26 +0100: > Le Mon, Jan 21, 2013 at 02:58:32PM +0000, Antoine Durant > [antoine.duran...@yahoo.fr] a écrit: > > Bonjour, > > > > Je viens ici pour avoir quelques conseils sur l'installation et la > > configuration apache pour un site à fort trafic (environ 80 millions > > de visiteurs sur un mois) > > > > Je pense partir sur du mode PHP CGI avec Apache2 mpm-worker. > > > > Quels sont les conseils ou exemple de configuration que vous pouvez me > > donner ?? > > Séparer les contenus statiques (images, css, ...) et ceux qui sont > générés dynamiquement, pour pouvoir, par exemple, aiguiller vers 2 > vhosts différents > Identifier, parmis les contenus générés dynamiquement ceux qui sont > spécifiques à un utilisateur (après qu'il se soit identifié, par > exemple) et ce qui est "commun", sur des masques d'urls séparés. > Fonction de tout ça, tu pourras répartir, et si besoin mettre un cache > (squid, varnish, ...) en reverse devant ton apache.
+1 Ne te laisse pas trop influencer par les conseils "utilise outil X plutôt que outil Y, c'est mieux, c'est vrai, je l'ai lu sur internet". C'est surtout grâce à une architecture judicieuse que tu vas réussir ton projet. Choisir des composants qui se prêtent bien au monitoring, c'est essentiel pour pouvoir "observer" ce qui se passe en production et faire les ajustements de configuration au fil du temps. Pour les backends, de la même façon que tu n'exposerais pas un tomcat ou un ruby on rails directement sur le web, évite d'exposer directement la brique php (quelle qu'elle soit) qui génère le contenu. php-fpm, apache & mod_php, php-cgi, peu importe. Le goulet d'étranglement ici ne sera pas de gérer le traffic mais de générer le contenu dynamiquement avec php. Comme cette étape est à priori la plus coûteuse en ressources, c'est important d'éviter de calculer plusieurs fois le même contenu. Pour cela, utilise des caches partout où cela est possible (paramétrage de la base de donnée, memcached, php-xcache, varnish/squid/nginx). De même, évite d'utiliser ton "compilateur de contenu" pour des tâches triviales tel que servir les CSS & pictos ou faire de la réécriture d'URL. Ensuite, la brique qui est en lien "direct" (ie: socket TCP) avec les navigateurs doit être légère et robuste. Son rôle est de choisir à quel backend transmettre les requêtes, et à faire "tampon" au niveau TCP. haproxy, nginx, pound, voire même du matos dédié (cisco et cie) sont les suspects usuels. Comme *tout* ton traffic passe par là, c'est un point privilégié pour observer ce qui se passe. Pour revenir au monitoring, à mon avis 2 outils se situent au-dessus de la moyenne au niveau "observabilité": haproxy et varnish. Bon courage pour ton projet, tiens-nous au courant ! À+, Marc PS: FWIW, apache a maintenant aussi un "event-driven MPM" (qui le rend donc asynchrone, comme nginx), mais je n'ai aucune expérience avec. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
