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 ?? Merci.
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci. _______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
Bonjour Frédéric, Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
________________________________ De : Frédéric de Villamil frederic@de-villamil.com À : Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group frsag@frsag.org Envoyé le : Lundi 21 janvier 2013 16h00 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci._______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
-- Frédéric de Villamil / @fdevillamil
I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net/
Salut,
Sauf à utiliser les fonctionnalités offertes par les htaccess, remplacer Apache par Nginx est une option plus viable... Il faut pas t'arrêter à des différences de syntaxe ou autre chez Nginx !
Le 21 janvier 2013 16:05, Antoine Durant antoine.durant29@yahoo.fr a écrit :
Bonjour Frédéric,
Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
*De :* Frédéric de Villamil frederic@de-villamil.com *À :* Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group < frsag@frsag.org> *Envoyé le :* Lundi 21 janvier 2013 16h00 *Objet :* Re: [FRsAG] Conf apache2 site fort trafic
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci. _______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
-- Frédéric de Villamil / @fdevillamil I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Quand tu dis remplacer Apache par Nginx est plus viable, tu peux m'en dire plus ? Nginx encaisse mieux les montées en charge qu'Apache ? Niveau configuration sous Nginx comment cela ce passe pour affiner la conf d'un site à forte visites ??
________________________________ De : Ludovic Cartier cartier.ludovic@gmail.com À : Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group frsag@frsag.org Cc : Frédéric de Villamil frederic@de-villamil.com Envoyé le : Lundi 21 janvier 2013 16h07 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Salut,
Sauf à utiliser les fonctionnalités offertes par les htaccess, remplacer Apache par Nginx est une option plus viable... Il faut pas t'arrêter à des différences de syntaxe ou autre chez Nginx !
Le 21 janvier 2013 16:05, Antoine Durant antoine.durant29@yahoo.fr a écrit :
Bonjour Frédéric,
Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
De : Frédéric de Villamil frederic@de-villamil.com À : Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group frsag@frsag.org Envoyé le : Lundi 21 janvier 2013 16h00 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci._______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
-- Frédéric de Villamil / @fdevillamil
I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/01/2013 16:12, Antoine Durant a écrit :
Bonjour,
Quand tu dis remplacer Apache par Nginx est plus viable, tu peux m'en dire plus ?
Nginx encaisse mieux les montées en charge qu'Apache ?
Apache est synchrone, Nginx est asynchrone Apache monte très vite en consommation mémoire, Nginx reste stable (maxi 5% constaté entre le repos et une charge de plusieurs millions de hits)
Niveau configuration sous Nginx comment cela ce passe pour affiner la conf d'un site à forte visites ??
Nginx sait délivrer du contenu static très rapidement, si tu lui dit que pour le php il doit l'envoyer à un serveur d'application php (PHP-FPM) alors il transmet la requête (comme un reverse proxy) et attend la réponse pour la renvoyer.
PHP-FPM c'est la clef pour avoir du php performant, au lieu d'avoir un processus lancé à chaque requête sur un apache, là une batterie de processus attendent les instructions. Du coup le cache opcode est toujours disponible, les processus ne perdent pas de temps à se lancer et à s'arrêter. PHP-FPM marche par pool, tu peux tout configurer dedans, avoir un php.ini commun avec des customs php pour chaque pool, ou un php.ini par pool, ...
Bref le jour et la nuit niveau performance.
Le 21/01/2013 16:18, Wallace a écrit :
PHP-FPM c'est la clef pour avoir du php performant, au lieu d'avoir un processus lancé à chaque requête sur un apache, là une batterie de processus attendent les instructions. Du coup le cache opcode est toujours disponible, les processus ne perdent pas de temps à se lancer et à s'arrêter. PHP-FPM marche par pool, tu peux tout configurer dedans, avoir un php.ini commun avec des customs php pour chaque pool, ou un php.ini par pool, ...
Moui, ca se fait aussi bien avec fastcgi non ? Même principe dans les grandes lignes même si la méthode de conf n'est pas vraiment la même (je m'y suis un peu perdu avec FPM au début, surtout quand il y a plusieurs vhosts avec un utilisateur chacun).
Mais on est d'accord sur le fait qu'avoir un gestionnaire de processus avec un pool de processus toujours dispos, c'est le must.
Julien
Bon... Au nombre d'arguement en faveur de Nginx je vais devoir l'essayer alors !!! Pour résumer j'install Nginx avec PHP-FPM c'est bien ça ? Faut-il configurer quelque chose pour PHP-FPM pour gérer du fort trafic ? En regardant sur google vite fait, l'avantage que j'y trouve est une install rapide et quasi fonctionnelle (pas de module comme apache ??) et moins gourmand qu'apache, je me trompe ?
________________________________ De : Wallace wallace@morkitu.org À : French SysAdmin Group frsag@frsag.org Envoyé le : Lundi 21 janvier 2013 16h18 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Le 21/01/2013 16:12, Antoine Durant a écrit :
Bonjour,
Quand tu dis remplacer Apache par Nginx est plus viable, tu peux m'en dire plus ? Nginx encaisse mieux les montées en charge qu'Apache ?
Apache est synchrone, Nginx est asynchrone Apache monte très vite en consommation mémoire, Nginx reste stable (maxi 5% constaté entre le repos et une charge de plusieurs millions de hits)
Niveau configuration sous Nginx comment cela ce passe pour affiner la conf d'un site à forte visites ??
Nginx sait délivrer du contenu static très rapidement, si tu lui dit que pour le php il doit l'envoyer à un serveur d'application php (PHP-FPM) alors il transmet la requête (comme un reverse proxy) et attend la réponse pour la renvoyer.
PHP-FPM c'est la clef pour avoir du php performant, au lieu d'avoir un processus lancé à chaque requête sur un apache, là une batterie de processus attendent les instructions. Du coup le cache opcode est toujours disponible, les processus ne perdent pas de temps à se lancer et à s'arrêter. PHP-FPM marche par pool, tu peux tout configurer dedans, avoir un php.ini commun avec des customs php pour chaque pool, ou un php.ini par pool, ...
Bref le jour et la nuit niveau performance.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
mettre le même nombre de worker que tu as de core est la base de la base, après c'est selon ta ram...
Christophe BAILLON Mobile :: +336 16 400 522 Home :: http://20h.com Twitter :: http://twitter.com/ctof
----- Mail original -----
De: "Antoine Durant" antoine.durant29@yahoo.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Lundi 21 Janvier 2013 16:24:52 Objet: Re: [FRsAG] Conf apache2 site fort trafic
Bon... Au nombre d'arguement en faveur de Nginx je vais devoir l'essayer alors !!! Pour résumer j'install Nginx avec PHP-FPM c'est bien ça ? Faut-il configurer quelque chose pour PHP-FPM pour gérer du fort trafic ? En regardant sur google vite fait, l'avantage que j'y trouve est une install rapide et quasi fonctionnelle (pas de module comme apache ??) et moins gourmand qu'apache, je me trompe ?
De : Wallace wallace@morkitu.org À : French SysAdmin Group frsag@frsag.org Envoyé le : Lundi 21 janvier 2013 16h18 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Le 21/01/2013 16:12, Antoine Durant a écrit :
Bonjour,
Quand tu dis remplacer Apache par Nginx est plus viable, tu peux m'en dire plus ?
Nginx encaisse mieux les montées en charge qu'Apache ?
Apache est synchrone, Nginx est asynchrone Apache monte très vite en consommation mémoire, Nginx reste stable (maxi 5% constaté entre le repos et une charge de plusieurs millions de hits)
Niveau configuration sous Nginx comment cela ce passe pour affiner la conf d'un site à forte visites ??
Nginx sait délivrer du contenu static très rapidement, si tu lui dit que pour le php il doit l'envoyer à un serveur d'application php (PHP-FPM) alors il transmet la requête (comme un reverse proxy) et attend la réponse pour la renvoyer.
PHP-FPM c'est la clef pour avoir du php performant, au lieu d'avoir un processus lancé à chaque requête sur un apache, là une batterie de processus attendent les instructions. Du coup le cache opcode est toujours disponible, les processus ne perdent pas de temps à se lancer et à s'arrêter. PHP-FPM marche par pool, tu peux tout configurer dedans, avoir un php.ini commun avec des customs php pour chaque pool, ou un php.ini par pool, ...
Bref le jour et la nuit niveau performance.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/01/2013 16:24, Antoine Durant a écrit :
Bon... Au nombre d'arguement en faveur de Nginx je vais devoir l'essayer alors !!! Pour résumer j'install Nginx avec PHP-FPM c'est bien ça ? Faut-il configurer quelque chose pour PHP-FPM pour gérer du fort trafic ? En regardant sur google vite fait, l'avantage que j'y trouve est une install rapide et quasi fonctionnelle (pas de module comme apache ??) et moins gourmand qu'apache, je me trompe ?
Oui, enfin, il faut quand même que tu configures tes pool php-fpm en précisant le nombre de processus à garder au repos, le nombre de processus php max, l'utilisateur qui exécutera (type suexec quoi).
Premier paramètre assez important : utilise un socket unix qu'un port réseau, c'est légèrement plus rapide (fois le nombre de requêtes, ça se sent).
Après, puisque tu sembles découvrir le truc, sache que l'on peut mettre nginx/apache/lighttpd (garder ton préféré) sur une machine et php-fpm sur une autre en utilisant des ports TCP pour FPM. Tu ne résonne donc plus forcément en x frontaux web, y BDD mais x frontaux http, y serveurs php et z BDD. Le multi-tier dans toute sa splendeur quoi.
Julien
Hello,
On 21/01/13 16:30, Julien Escario wrote:
Premier paramètre assez important : utilise un socket unix qu'un port réseau, c'est légèrement plus rapide (fois le nombre de requêtes, ça se sent).
Oui, et surtout niveau sécu, une config s'appuyant sur une socket réseau permet à quiconque ayant un accès sur la machine (y compris un autre vhost) d'exécuter du code sous l'uid de n'importe quel vhost...
Par axemple avec ça : https://github.com/adoy/PHP-FastCGI-Client/blob/master/fastcgi.php
Le 21/01/2013 17:18, Olivier Le Cam a écrit :
Hello,
Oui, et surtout niveau sécu, une config s'appuyant sur une socket réseau permet à quiconque ayant un accès sur la machine (y compris un autre vhost) d'exécuter du code sous l'uid de n'importe quel vhost...
Par axemple avec ça : https://github.com/adoy/PHP-FastCGI-Client/blob/master/fastcgi.php
Oui tout à fait, c'est pour cela que les sockets réseaux doivent être réservés à des architectures dédiées. Perso j'utilise les sockets réseaux que lorsque php-fpm est sur des machines dédiées et les web nginx sur d'autres. Mais en aucun cas la plate-forme ne fait tourner plusieurs sites différents.
Merci pour l'info de la class en effet cela devient encore plus facile si c'est pas étanche, j'avoue que j'avais pas chercher cela me paraissait évident de pas procéder ainsi.
Re... Par contre la génération des log access par Nginx est compatible avec Awstat ou faut-il faire une conf spéciale ?
Le 21/01/2013 21:19, Antoine Durant a écrit :
Re...
Par contre la génération des log access par Nginx est compatible avec Awstat ou faut-il faire une conf spéciale ?
Oui, je sais plus si c'est par défaut mais j'ai une log custom qui récupère le remote ip quand y a des reverse proxy en amont et que j'ai écrit pour être identique à Apache.
Sinon Awstats s'adapte aussi à l'inverse à n'importe quelle ligne de log, suffit de lui indiquer la syntaxe dans le fichier de config global ou pour chaque site.
Le 21/01/2013 16:24, Antoine Durant a écrit :
Bon... Au nombre d'arguement en faveur de Nginx je vais devoir l'essayer alors !!!
Pour résumer j'install Nginx avec PHP-FPM c'est bien ça ?
Oui pour un web de base, là je pense que ton archi est plus complexe. Sachant que tu peux avoir des serveurs dédiés à PHP-FPM comme un Tomcat par ex et seulement quelques web en amont. Ton autre problématique va être aussi ta base de donnée, la réplication des données, cache ou pas cache, ...
Dans ton cas une étude me semble nécessaire.
Faut-il configurer quelque chose pour PHP-FPM pour gérer du fort trafic ?
Comme tu configurerais ton php.ini pour de la prod performante, après c'est en fonction de tes ressources dispos que tu vas allouer plus ou moins de processus qui tournent. Là y a pas de secret faut faire des tirs de perfs pour trouver tes réglages et exploiter au mieux tes machines.
En regardant sur google vite fait, l'avantage que j'y trouve est une install rapide et quasi fonctionnelle (pas de module comme apache ??) et moins gourmand qu'apache, je me trompe ?
Complètement Nginx ne consomme rien en ram, j'ai déjà fait des VM en reverse proxy sans cache avec juste 256Mo de ram sur une Debian et ça encaissait dans les 500req/sec en pointe sans broncher.
Merci pour les retours... Quelqu'un aurait un exemple concret de configuration d'un site à fort trafic à me montrer ou pas ??
Le 21/01/2013 16:37, Antoine Durant a écrit :
Merci pour les retours...
Quelqu'un aurait un exemple concret de configuration d'un site à fort trafic à me montrer ou pas ??
Oui mais cela dépend de ton environnement, si y a du cache fait en amont ou par Nginx, ... Pour php c'est pareil et encore plus dépendant des ressources disponibles et celle que ton applicatif va consommer. Si tu as un site qui se contente de 32Mo de memory limit php tu pourras lancer bien plus de processus qu'un gros CMS où on te demande de mettre entre 300 et 512Mo. J'ai eu le cas récemment on m'a demandé du 512Mo pour des applications et le serveur n'avait que 2Go de ram, j'ai mis un gros warning au client et j'ai limité à 3 processus maximum, ne sachant pas ce qu'il comptait utiliser.
Hello,
Le Monday 21 January 2013 à 15:37, Antoine Durant écrivait:
Quelqu'un aurait un exemple concret de configuration d'un site à fort trafic à me montrer ou pas ??
C'est spécifique pour http://piwik.org/, mais deseigné pour du fort trafic: https://github.com/perusio/piwik-nginx
C'est spécifique pour http://piwik.org/, mais deseigné pour du fort trafic: https://github.com/perusio/piwik-nginx
Y'a que mois ou ton site est injoignable???
Si Apache est mandatory, tu peux utiliser HAProxy et son systeme de queue pour fluidifier le traffic vers ton apache et lui sauver les miches. HAProxy gérera les connections vers les clients et n'ouvrira que les connexions necessaires sur le serveur (en gros ça correspond aux requeêtes HTTP en cours d'exécution). Ca protège automatiquement ton apache du slowloris, etc..
a+
Niveau perf, les logs FPM sont très "bavard" pour t'aider dans ta conf genre "tu dois augmenter cette valeur ou celle là".
Moi j'utilise lighttpd (même fonctionnement que nginx) et FPM, des fois nginx. Mais généralement remplacer apache par nginx ou lighttpd sur du gros traffic me fait gagner au bas mot 80% de puissance. Le dernier client où j'ai fait cette migration, on est passé de 5 serveurs à 1 seul.
Niveau "dev" sinon pour la suite, je conseille un sous domaine pour le static qui permettra un jour de faire pointer ça où on veut.
Ce que je vois, c'est que ma conf nginx ou lighttpd pour un gros site va faire au max 60 lignes en un seul fichier (si paquet Debian, ils ont commencé à exploser en plein de fichiers, je suis pas fan) comparé à Apache, la maintenance reste nettement plus simple.
Le gros avantage aussi c'est vu que c'est "moins utilisé" par l'admin sys du dimanche, tu trouveras des infos moins nombreuses, mais de meilleure qualité.
Pour PHP FPM, t'as pas mal d'indication dans la conf de base (conf qui tient pas mal la route par défaut) style : ; Default Value: min_spare_servers + (max_spare_servers - min_spare_servers) / 2 pm.start_servers = 20
Le 21/01/2013 16:24, Antoine Durant a écrit :
Bon... Au nombre d'arguement en faveur de Nginx je vais devoir l'essayer alors !!! Pour résumer j'install Nginx avec PHP-FPM c'est bien ça ? Faut-il configurer quelque chose pour PHP-FPM pour gérer du fort trafic ? En regardant sur google vite fait, l'avantage que j'y trouve est une install rapide et quasi fonctionnelle (pas de module comme apache ??) et moins gourmand qu'apache, je me trompe ?
*De :* Wallace wallace@morkitu.org *À :* French SysAdmin Group frsag@frsag.org *Envoyé le :* Lundi 21 janvier 2013 16h18 *Objet :* Re: [FRsAG] Conf apache2 site fort trafic
Le 21/01/2013 16:12, Antoine Durant a écrit :
Bonjour, Quand tu dis remplacer Apache par Nginx est plus viable, tu peux m'en dire plus ? Nginx encaisse mieux les montées en charge qu'Apache ?
Apache est synchrone, Nginx est asynchrone Apache monte très vite en consommation mémoire, Nginx reste stable (maxi 5% constaté entre le repos et une charge de plusieurs millions de hits)
Niveau configuration sous Nginx comment cela ce passe pour affiner la conf d'un site à forte visites ??
Nginx sait délivrer du contenu static très rapidement, si tu lui dit que pour le php il doit l'envoyer à un serveur d'application php (PHP-FPM) alors il transmet la requête (comme un reverse proxy) et attend la réponse pour la renvoyer.
PHP-FPM c'est la clef pour avoir du php performant, au lieu d'avoir un processus lancé à chaque requête sur un apache, là une batterie de processus attendent les instructions. Du coup le cache opcode est toujours disponible, les processus ne perdent pas de temps à se lancer et à s'arrêter. PHP-FPM marche par pool, tu peux tout configurer dedans, avoir un php.ini commun avec des customs php pour chaque pool, ou un php.ini par pool, ...
Bref le jour et la nuit niveau performance.
Bonjour,
Dans ce cas, il faut éviter CGI pour php. En effet, à chaque requête, un process php doit être créé et tué ce qui coute beaucoup de ressources. Après entre mod_php et fcgi ça se tient à peu près. Pour servir plus de requêtes, tu peux utiliser un varnish en cache reverse proxy si tu as une bonne vue sur l'applicatif qui tourne sous apache.
Kévin.
Le 21-01-2013 16:05, Antoine Durant a écrit :
Bonjour Frédéric,
Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
DE : Frédéric de Villamil frederic@de-villamil.com À : Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group frsag@frsag.org ENVOYÉ LE : Lundi 21 janvier 2013 16h00 OBJET : Re: [FRsAG] Conf apache2 site fort trafic
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci._______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
-- Frédéric de Villamil / @fdevillamil
I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net/ [1]
Links:
[1] http://t37.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Et surtout penser a la bande passante. En estimation faible, tes 80M de visites par mois, c'est 100 visites par secondes pendant les periodes chaudes (3x Avg) Si une visite complete prend en gros 2Mo (a voir selon ton site, avec l'html/php/images/css...), tu vas pousser 1,6Gbps en pointe.
On 21/01/13 16:10, Kévin MET wrote:
Bonjour,
Dans ce cas, il faut éviter CGI pour php. En effet, à chaque requête, un process php doit être créé et tué ce qui coute beaucoup de ressources. Après entre mod_php et fcgi ça se tient à peu près. Pour servir plus de requêtes, tu peux utiliser un varnish en cache reverse proxy si tu as une bonne vue sur l'applicatif qui tourne sous apache.
Kévin.
Le 21-01-2013 16:05, Antoine Durant a écrit :
Bonjour Frédéric,
Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
DE : Frédéric de Villamil frederic@de-villamil.com À : Antoine Durant antoine.durant29@yahoo.fr; French SysAdmin Group frsag@frsag.org ENVOYÉ LE : Lundi 21 janvier 2013 16h00 OBJET : Re: [FRsAG] Conf apache2 site fort trafic
Le 21 janv. 2013 à 15:58, Antoine Durant antoine.durant29@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 ??
Merci._______________________________________________
Bonjour,
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
-- Frédéric de Villamil / @fdevillamil
I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net/ [1]
Links:
[1] http://t37.net/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/01/2013 16:05, Antoine Durant a écrit :
Bonjour Frédéric,
Oui Apache est un prérequis car c'est celui que l'on maitrise et utilise le plus souvent.
Nginx s'apprend rapidement, ressemble à Apache (modules en moins). Et au final c'est pas plus mal que les langages soit renvoyé vers des serveurs d'application dédié à PHP ou autre (un peu comme Tomcat finalement).
Autre argument très puissant quand les développeurs ne veulent ou ne peuvent pas gérer du cache, c'est mettre en cache la sortie de PHP entre Nginx et PHP c'est radical.
Bref que des avantages faut juste apprendre un nouvel outils qui à mon sens est très lisible en syntax comparé à d'autres serveurs.
Le 21/01/2013 16:00, Frédéric de Villamil a écrit :
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
Tout pareil Apache est a éviter, le dernier dossier géré avec on m'imposait 3M de VU/jour sur trois frontaux Apache. Nginx soit disant impossible (plutôt frileux car je bosse avec depuis 5 ans sans soucis), du coup j'ai mis la pression sur les équipes de développement pour que le Drupal soit caché au maximum. Au final l'archi a tenu juste les 3M de VU/jour et ils ont rajoutés des serveurs alors que de mes tests Nginx tenait avec 40% de charge en moins.
Nginx tient super bien la charge en tant que serveur web ou reverse proxy. Un Varnish peu être pas mal si vous avez un besoin en règles particulières au niveau du reverse.
Bref Apache n'existe plus chez nous depuis 5 ans sauf exception et encore on préfère refuser un projet que de maintenir un Apache avec des htaccess (on a vu cette aberration imposée par des dev une fois ...)
Le 21/01/2013 16:11, Wallace a écrit :
Le 21/01/2013 16:00, Frédéric de Villamil a écrit :
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
Tout pareil Apache est a éviter, le dernier dossier géré avec on m'imposait 3M de VU/jour sur trois frontaux Apache. Nginx soit disant impossible (plutôt frileux car je bosse avec depuis 5 ans sans soucis), du coup j'ai mis la pression sur les équipes de développement pour que le Drupal soit caché au maximum. Au final l'archi a tenu juste les 3M de VU/jour et ils ont rajoutés des serveurs alors que de mes tests Nginx tenait avec 40% de charge en moins.
Tiens, je digresse : tu utilises quoi pour faire des tests de charge aussi importants ?
Récemment, je me suis heurté à une limitation qui ne semblait pas venir d'Apache ou de php puisque le serveur se la coulait douce (il restait des slots dispos) et pourtant des connexions étaient refusées. Ca semblait venir plutôt de la pile TCP/IP de mon Linux, un 2.6. Mes tests de charge depuis une machine connectée dessus se passaient parfaitement bien mais au moment du passage en prod, il semblerait que le nombre de sessions TCP à maintenir aient créé un blocage.
Si quelqu'un a une piste, je suis preneur.
Julien
Le 21/01/2013 16:20, Julien Escario a écrit :
Tiens, je digresse : tu utilises quoi pour faire des tests de charge aussi importants ?
- AB, boucle de wget pour faire du test de base et du debug sur certaines urls - Tsung pour faire des scénarios de visiteurs ou rejouer une plage de temps de surf normal de la plate-forme actuellement en prod - un autre outils que j'ai pas utilisé depuis un bout de temps mais qui est génial, tu enregistres une session surf dans FF et il te sort le code Perl qui correspond. Après tu peux le rejouer, modifier, paralléliser. Je l'utilisais à une époque pour la supervision applicative avancée mais je suis passé sur des librairies persos en PHP à présent.
Récemment, je me suis heurté à une limitation qui ne semblait pas venir d'Apache ou de php puisque le serveur se la coulait douce (il restait des slots dispos) et pourtant des connexions étaient refusées. Ca semblait venir plutôt de la pile TCP/IP de mon Linux, un 2.6.
Ha oui là on parle web mais un kernel optimisé et léger, avec quelques patchs pour la sécurité et l'optimisation, plus les bons paramètres du kernel c'est plus important que de savoir sur quel serveur web on part. Nombre d'audits où j'ai trouvé que les tables de conntrack étaient pleine alors que le serveur était chargé à 40% ... et les clients qui voulaient racheter plein de serveurs On oublie un peu souvent mais les paramètres par défaut des Linux sont fait pour la configuration minimale sur laquelle ils sont sensés tourner, donc on applique pas les mêmes réglages à un bi xeon 8 coeurs avec des cartes low latency qu'à un pentium 2 256Mo de Ram qui fait tourner la même Debian...
L'hébergement web performant c'est intervenir sur toutes les couches, le réseau wan, le réseau lan, les serveurs, les systèmes, les serveurs applicatifs, l'application, les méthodes utilisateurs
Mes tests de charge depuis une machine connectée dessus se passaient parfaitement bien mais au moment du passage en prod, il semblerait que le nombre de sessions TCP à maintenir aient créé un blocage.
- conntrack activé? - nombre maxi de fichier pouvant être ouverts? - taille max du segment de mémoire partagée? ...
Si quelqu'un a une piste, je suis preneur.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/01/2013 16:28, Wallace a écrit :
Le 21/01/2013 16:20, Julien Escario a écrit :
Tiens, je digresse : tu utilises quoi pour faire des tests de charge aussi importants ?
- AB, boucle de wget pour faire du test de base et du debug sur
certaines urls
- Tsung pour faire des scénarios de visiteurs ou rejouer une plage de
temps de surf normal de la plate-forme actuellement en prod
- un autre outils que j'ai pas utilisé depuis un bout de temps mais qui
est génial, tu enregistres une session surf dans FF et il te sort le code Perl qui correspond. Après tu peux le rejouer, modifier, paralléliser. Je l'utilisais à une époque pour la supervision applicative avancée mais je suis passé sur des librairies persos en PHP à présent.
SIEGE / SPROXY ? Tsung est en attente de test depuis plusieurs semaines ;-) Faut que je trouve un peu de temps.
Mon soucis était plutôt de générer des requêtes semblant venir de plein d'IPs différentes mais je dois pouvoir bricoler ça avec un peu de shell, la RFC1918 et mes routeurs.
L'hébergement web performant c'est intervenir sur toutes les couches, le réseau wan, le réseau lan, les serveurs, les systèmes, les serveurs applicatifs, l'application, les méthodes utilisateurs
Ouais, un peu comme la sécurité quoi ;-)
Mes tests de charge depuis une machine connectée dessus se passaient parfaitement bien mais au moment du passage en prod, il semblerait que le nombre de sessions TCP à maintenir aient créé un blocage.
- conntrack activé?
- nombre maxi de fichier pouvant être ouverts?
- taille max du segment de mémoire partagée?
...
Conntrack desactivé, pareil pour la protection syn flood. Par contre, le nombre de filehandle autorisés pour Apache y est peut être pour quelque chose.
Idem pour shmmax : j'ai 32 Mo, ça peut être un facteur limitant ? # cat /proc/sys/kernel/shmmax 33554432
Bizarre quand même, mes tests avec ab depuis une machine connectée sur le même subnet donnaient de bons résultats. Va falloir que je reproduise le truc pour comprendre une bonne fois pour toutes.
Julien
Le 21/01/2013 16:53, Julien Escario a écrit :
SIEGE / SPROXY ?
Siege ça fait un bout de temps que je l'ai pas utilisé.
Tsung est en attente de test depuis plusieurs semaines ;-) Faut que je trouve un peu de temps.
Mon soucis était plutôt de générer des requêtes semblant venir de plein d'IPs différentes mais je dois pouvoir bricoler ça avec un peu de shell, la RFC1918 et mes routeurs.
Tsung a par un cas chez un client en tant que prestataire où on a marché avec deux machines, depuis j'ai toujours pris des machines physique ou virtuelle à proximité immédiate des serveurs à tester tout en passant par les équipements firewall, LB, cache pour être précis.
Du coup la majorité des petites et moyennes installations se testent avec 4 machines qui peuvent avoir plein d'ip en alias Tsung peut être configuré pour les utiliser aléatoirement. Pour les gros tests, le mieux c'est de capturer du vrai trafic à des heures de pointes et changer les ip par des pools entiers de rfc1918 et de configurer une bonne dizaine de grosses machines avec un kernel super light et très optimisé réseau et avec surtout plein de cartes réseaux pour avoir plein d'irq différents.
Avec cela tu génères une charge de folie en moins de deux.
L'hébergement web performant c'est intervenir sur toutes les couches, le réseau wan, le réseau lan, les serveurs, les systèmes, les serveurs applicatifs, l'application, les méthodes utilisateurs
Ouais, un peu comme la sécurité quoi ;-)
oui :D
Conntrack desactivé, pareil pour la protection syn flood. Par contre, le nombre de filehandle autorisés pour Apache y est peut être pour quelque chose.
Idem pour shmmax : j'ai 32 Mo, ça peut être un facteur limitant ? # cat /proc/sys/kernel/shmmax 33554432
euh oui si tu utilises du cache apc ou xcache, si ta machine fait plusieurs giga de ram et est dédiée à apache / php, ... Après normalement en activant un peu de debug des processus tu devrais voir des warning si le problème vient de la mémoire partagée. De base je met 134217728 128Mo sur shmall et shmmax après c'est du custom en fonction de ce qui tourne dessus. Si la machine est bon à tout faire ça suffit souvent, si c'est un serveur dédié php-fpm je règle en fonction du cache apc max et de la taille max des objets apc.
Bizarre quand même, mes tests avec ab depuis une machine connectée sur le même subnet donnaient de bons résultats. Va falloir que je reproduise le truc pour comprendre une bonne fois pour toutes.
AB n'est pas fiable à 100%, on me l'a démontré une fois mais je ne me rappel plus exactement pourquoi. Faut le voir comme un wget automatisé avec un rapport propre sur ce qui a marché et n'a pas marché. Si ton nombre de requêtes / sec traitées sans erreur est au dessus de 300/400 considère que ça marche déjà bien mais faut pas s’emballer en voyant 3500req/sec en se disant c'est bon je suis tranquille. Avec un Tsung ou Siege tu verras toute de suite la différence quand un vrai scénario tourne. Le trafic normal est plutôt une anomalie qu'un flux standard comme AB sur une seule url.
Le 21/01/2013 16:20, Julien Escario a écrit :
Le 21/01/2013 16:11, Wallace a écrit :
Le 21/01/2013 16:00, Frédéric de Villamil a écrit :
Apache est-il un prérequis absolu ? As-tu regardé du coté de nginx + php-fpm ?
Tout pareil Apache est a éviter, le dernier dossier géré avec on m'imposait 3M de VU/jour sur trois frontaux Apache. Nginx soit disant impossible (plutôt frileux car je bosse avec depuis 5 ans sans soucis), du coup j'ai mis la pression sur les équipes de développement pour que le Drupal soit caché au maximum. Au final l'archi a tenu juste les 3M de VU/jour et ils ont rajoutés des serveurs alors que de mes tests Nginx tenait avec 40% de charge en moins.
Tiens, je digresse : tu utilises quoi pour faire des tests de charge aussi importants ?
Perso j'ai laissé tsung de côté pour Funkload : http://funkload.nuxeo.org/
Un proxy permet d'enregistrer le scénario de test, qui peut ensuite être rejoué de manière distribuée sur de nombreux serveurs.
Yann
Le Mon, Jan 21, 2013 at 02:58:32PM +0000, Antoine Durant [antoine.durant29@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.
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.durant29@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.
Le 22/01/2013 07:53, Marc Fournier a écrit :
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.
Oui en effet, je ne l'ai pas testé mais des retours de partenaires en production indiquent que la consommation mémoire d'Apache reste toujours aussi importante lors de forte charge lorsqu'il est couplé avec des mod_php. En les migrants sur du Nginx pour la couche PHP le gain a été immédiat pour plusieurs milliers de VU/jour. Néanmoins il serait intéressant de le tester pour des usages où Apache est encore plus pratique à déployer que d'autres solutions, je pense notamment à Passenger.
Le 22/01/2013 07:53, Marc Fournier a écrit :
Hello Antoine,
Excerpts from Dominique Rousseau's message of 2013-01-21 16:14:26 +0100:
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.
+1
Pour avoir plus de 10x le trafic que tu annonces sur des serveurs Apache2, je peux te dire que ça tient, et ça tient les montés en charge.
NGiNX est un excellent serveur HTTP, je l'ai d'ailleurs mis en amont, mais mes Apache encaisse encore 1000 qps. Un Apache2 bien configuré sera meilleur qu'un NGiNX stock, et vice-versa. J'ai réfléchi à migrer tout mes Apache sous NGiNX, et je me heurte à un besoin tout bête : l'équivalent de RewriteCond. Sous NGiNX ça se fait avec "if" mais la doc de Nginx a une page dédié au découragement de son utilisation : IfIsEvil http://wiki.nginx.org/IfIsEvil
Avec ma stack NGiNX + Apache2/mod_php, finalement je peux faire ce que je veux avec des perfs plus qu'honorable et une montée en charge sans soucis, d'ailleurs, ce qui me pose soucis aujourd'hui lors de montée en charge violente, c'est le code PHP et ses connexions à memcached, memcached qui part en sucette... Vivement qu'ils aient tout passé sur Redis !
Bonne journée !
Le 23/01/2013 10:10, Gregory Duchatelet a écrit :
NGiNX est un excellent serveur HTTP, je l'ai d'ailleurs mis en amont, mais mes Apache encaisse encore 1000 qps. Un Apache2 bien configuré sera meilleur qu'un NGiNX stock, et vice-versa.
As tu fais ton calcul de ressources? Car entre un Apache bien configuré et un Nginx bien configuré, les ressources nécessaires ne sont pas du tout les mêmes, la seule limite qui vient gâcher un peu le gain c'est d'avoir un kernel ultra optimisé et des cartes réseaux multi irq. J'ai consolidé des archis où on est passé de plusieurs dizaine d'Apache à moins d'une dizaine de Nginx. Quand tu fais le calcul du prix du serveur, électricité, espace housing, ... le client était ravi. Et en plus on a gagné en tenue de charge.
J'ai réfléchi à migrer tout mes Apache sous NGiNX, et je me heurte à un besoin tout bête : l'équivalent de RewriteCond. Sous NGiNX ça se fait avec "if" mais la doc de Nginx a une page dédié au découragement de son utilisation : IfIsEvil http://wiki.nginx.org/IfIsEvil
C'est les rewrites rules dans les configurations des vhosts ou pire des .htaccess qui sont evil. Si tu dois faire des redirections en amont pour traiter l'historique de tes sites (changement d'url, opération spéciale, ...) cela devrait être réservé au reverse proxy qui dans ton cas devrait plutôt être sous Varnish si tu as des besoins plus larges que des if à mettre en place. Les applications depuis quelques années (CMS, Framework, custom dev) gèrent les redirections en interne et finalement la configuration d'un Apache ou Nginx consiste à renvoyer les fichiers ou répertoires qui n'existent pas à index.php ou autre.
Du coup cela te libère de cette contrainte.
Dans deux cas clients avec du custom dev et des pages et des pages de rewrite apache, on s'est orienté vers un redirect.php qui gère tout cela pour simplifier les rewrites et finalement redonner la main sur ce réglage au client (il le met dans ses livraisons).
Avec ma stack NGiNX + Apache2/mod_php, finalement je peux faire ce que je veux avec des perfs plus qu'honorable et une montée en charge sans soucis, d'ailleurs, ce qui me pose soucis aujourd'hui lors de montée en charge violente, c'est le code PHP et ses connexions à memcached, memcached qui part en sucette... Vivement qu'ils aient tout passé sur Redis !
Des soucis avec memcached, tu dois pas y aller de main morte :D
Bonjour, Quelqu'un as un bon tuto/source pour configurer correctement un apache2 avec mpm-worker ? Les différents paramètres suivant la mémoire disponible, le nombre de core cpu... Merci
________________________________ De : Wallace wallace@morkitu.org À : frsag@frsag.org Envoyé le : Mercredi 23 janvier 2013 11h52 Objet : Re: [FRsAG] Conf apache2 site fort trafic
Le 23/01/2013 10:10, Gregory Duchatelet a écrit :
NGiNX est un excellent serveur HTTP, je l'ai d'ailleurs mis en
amont, mais mes Apache encaisse encore 1000 qps. Un Apache2 bien configuré sera meilleur qu'un NGiNX stock, et vice-versa. As tu fais ton calcul de ressources? Car entre un Apache bien configuré et un Nginx bien configuré, les ressources nécessaires ne sont pas du tout les mêmes, la seule limite qui vient gâcher un peu le gain c'est d'avoir un kernel ultra optimisé et des cartes réseaux multi irq. J'ai consolidé des archis où on est passé de plusieurs dizaine d'Apache à moins d'une dizaine de Nginx. Quand tu fais le calcul du prix du serveur, électricité, espace housing, ... le client était ravi. Et en plus on a gagné en tenue de charge.
J'ai réfléchi à migrer tout mes Apache sous NGiNX, et je me heurte à un besoin tout bête : l'équivalent de RewriteCond. Sous NGiNX ça se fait avec "if" mais la doc de Nginx a une page dédié au découragement de son utilisation : IfIsEvil
C'est les rewrites rules dans les configurations des vhosts ou pire des .htaccess qui sont evil. Si tu dois faire des redirections en amont pour traiter l'historique de tes sites (changement d'url, opération spéciale, ...) cela devrait être réservé au reverse proxy qui dans ton cas devrait plutôt être sous Varnish si tu as des besoins plus larges que des if à mettre en place. Les applications depuis quelques années (CMS, Framework, custom dev) gèrent les redirections en interne et finalement la configuration d'un Apache ou Nginx consiste à renvoyer les fichiers ou répertoires qui n'existent pas à index.php ou autre.
Du coup cela te libère de cette contrainte.
Dans deux cas clients avec du custom dev et des pages et des pages de rewrite apache, on s'est orienté vers un redirect.php qui gère tout cela pour simplifier les rewrites et finalement redonner la main sur ce réglage au client (il le met dans ses livraisons).
Avec ma stack NGiNX + Apache2/mod_php, finalement je peux faire ce
que je veux avec des perfs plus qu’honorable et une montée en charge sans soucis, d'ailleurs, ce qui me pose soucis aujourd'hui lors de montée en charge violente, c'est le code PHP et ses connexions à memcached, memcached qui part en sucette... Vivement qu'ils aient tout passé sur Redis !
Des soucis avec memcached, tu dois pas y aller de main morte :D
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Antoine Durant -
Aurélien Beaujean -
Baptiste -
Boris Pigeot -
Christophe BAILLON -
Dominique Rousseau -
Frédéric de Villamil -
Gregory Duchatelet -
Julien Escario -
Kévin MET -
Ludovic Cartier -
Marc Fournier -
Olivier Le Cam -
Thomas Pedoussaut -
Wallace -
Yann Autissier