Mettre en place un Reverse Proxy Nginx sur son serveur
| Nb visites : 4 549 |
A cause (ou grâce) au petit concours que j’ai lancé pour gagner le Nokia N900, vous êtes trèèèèèèès nombreux à être sur le site, à laisser un commentaire puis après aller vous ballader sur mes autres articles. C’est bien (yeah!) sauf que du coup l’Apache qui fait tourner le site a eu un peu de mal à gérer l’affluence.
J’ai donc du mettre en place un petit serveur Nginx pour faire office de Reverse Proxy afin d’alleger le tout. Je ne me prétend pas expert en nginx mais je vais tenter de vous expliquer avec mes mots (c’est à dire simplement) comment mettre ça en place chez vous.
Mais avant ça, petit cours de comment fonctionne un serveur http classique type Apache !
Lorsque vous arrivez avec votre petit navigateur sur Korben.info (qui tourne sous wordpress), voici ce qui se passe :
- Votre ordinateur envoie une demande de connexion au serveur Apache
- Votre navigateur peut alors se connecter au serveur Apache
- Apache crée alors un nouveau process pour gérer votre demande
- Si c’est du contenu statique que vous demandez (genre une image), Apache va la chercher et vous l’envoie (facile)
- Mais si c’est du contenu dynamique (genre page en PHP), Apache la demande et doit attendre que PHP (souvent en appelant un petit coup MySQL dans la foulée) ai fini de générer cette page pour vous la renvoyer.
- Votre navigateur reçoit alors le fichier demandé, il ferme la connexion avec l’Apache et vous affiche le contenu demandé
Great !
Sauf que ce qu’on ne vous dit pas, c’est qu’en cas de nombreuses demandes, votre Apache il souffre sa race ! En effet, il peut en quelques minutes bouffer toute la mémoire de votre serveur et faire tourner le CPU à plus de 100 % ! Pas cool ! Une des solutions consisterait donc à acheter un plus gros serveur mais avant de sortir le chéquier, il est possible de l’optimiser encore un petit peu.
On peut en effet confier la distribution des fichiers statiques à un serveur comme Nginx qui a l’avantage d’être très rapide pour exécuter cette tâche. La mémoire vive consommée par Nginx est très réduite, ce qui permet de le charger un peu sans exploser la mémoire. Ayant déjà une architecture Apache en place, je ne voulais pas passer ma nuit à tout migrer sur Nginx en tant que serveur web (et surtout ne pas me prendre la tête avec les reécriture d’URL qui se gère un peu différemment sous Nginx). J’ai donc décider de l’utiliser comme un Reverse Proxy. C’est à dire de faire tourner l’Apache (avec le blog et tout et tout) sur un autre port uniquement en local sur mon serveur et de demander à Nginx de s’occuper de la distribution de contenu pour vous mes fidèles visiteurs 
Au niveau du contenu statique, j’ai un sous domaine pictures.korben.info qui diffuse uniquement les images du site. J’ai donc choisi de faire distribuer ces fichiers directement par le Nginx plutôt que par Apache. Autre avantages de Nginx, c’est qu’il gère le loadbalancing, ce qui sera pratique quand je commencerai à faire plus de trafic que Facebook… (ouais j’y crois !!!)
Voici au final à quoi ressemble la config que j’ai mis en place :
Z’avez vu ? Je fais des beaux schémas ! C’est grâce à Pencil qui est sorti en 1.1 RC1 (ça c’était la news dans la news !!)
Bref, trêve de blabla, si vous êtes chaud, on attaque !
Avant tout, vous allez stopper votre Apache (sudo /etc/init.d/apache2 stop). Puis on va installer Nginx
sudo apt-get install nginx
Ensuite, on va éditer le fichier /etc/nginx/nginx.conf
Voici ce que j’ai mis dans le mien :
user www-data; worker_processes 2; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; access_log /var/log/nginx/access.log; server_names_hash_bucket_size 64; sendfile on; tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; tcp_nodelay on; gzip on; gzip_comp_level 5; gzip_http_version 1.0; gzip_min_length 0; gzip_types text/plain text/html text/css image/x-icon application/x-javascript; gzip_vary on; include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; }
worker_processes à 2, c’est pour indiquer le nombre d’instance de Nginx que je souhaite lancer pour traiter tout ce business… J’ai mis à 2 pour voir et je réduirai / augmenterai après mes tests.
worker_connections à 1024, cela veut dire que chaque process est capable d’encaisse 1024 connexions simultannées (pas visiteurs hein, connexions !). Pour le reste, je vous invite à lire la doc mais globalement, j’ai activé la compression gzip pour que ça booste encore un peu plus et j’ai laissé le timeout à 65 secondes.
A la fin, vous pouvez voir que j’apelle tous les .conf dans /conf.d/ et tous les /sites-enabled/
On va donc aller éditer ces fichiers.
Commençons par /conf.d/proxy.conf. Voici ce qu’il faut mettre dedans pour qu’il fonctionne comme un proxy. Idem pour la doc si vous voulez en savoir plus sur les paramètres mais globalement, vous pouvez régler ici les tailles de buffers pour gérer les entêtes et corps envoyés par les clients afin de pouvoir par exemple récuperer des gros cookies ou ce genre de choses (de ce que j’ai pu comprendre).
proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10m; client_body_buffer_size 128k; client_header_buffer_size 64k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_busy_buffers_size 64k;
Et pour finir, dans site-enabled, un peu comme dans la config Apache, j’ai édité le fichier default dans lequel j’ai mis les choses suivantes (mes commentaires sont dans le code ci-dessous) :
#PREMIERE CONFIG : Ici je dit que sur le port 80, pour le domaine #korben.info, nginx va chercher les pages en local (127.0.0.1) #sur l'Apache qui est configuré en port 8080 server { listen 80; server_name korben.info; access_log /var/log/korben.access.log; error_log /var/log/korben.nginx_error.log debug; location / { proxy_pass http://127.0.0.1:8080/; } #Et je rajoute PHPMYADMIN dans la foulée location /phpmyadmin { proxy_pass http://127.0.0.1:8080/phpmyadmin; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/nginx-default; } } #SECONDE CONFIG : Ici je dit que sur le port 80, tout ce qui est #pour le domaine pictures.korben.info doit être envoyé directement #par le Nginx et se trouve dans le repertoire /var/www/monsite/wp-content/uploads/ server { listen 80; server_name pictures.korben.info; location = /50x.html { root /var/www/nginx-default; } access_log /var/log/pictures.nginx.access.log; error_log /var/log/picture.nginx.error.log; index index.html; location / { expires max; root /var/www/monsite/wp-content/uploads/; } }
Ayé, on a fait le plus dur. Maintenant, on va configurer l’Apache pour qu’il cause sur le port 8080 uniquement. Voici ce que j’ai mis dans le fichier /etc/apache2/ports.conf
NameVirtualHost * Listen 127.0.0.1:8080
Et dans mes site-enabled Apache, j’ai bien mis en début de fichier afin d’indiquer une nouvelle fois (on n’est jamais trop prudent) que tout se passe sur le port 8080.
Dernière petite chose. Pour que l’Apache logue correctement les IPs qui se connectent à votre serveur, il faut installer le module suivant :
sudo apt-get install libapache2-mod-rpaf
Et voilà ! Il ne reste plus qu’à démarrer l’Apache sur son nouveau port, et le Nginx sur le port 80.
- sudo /etc/init.d/apache2 start
- sudo /etc/init.d/nginx restart (ou reload ou start)
Allez ensuite sur votre site et si ça ne fonctionne pas c’est que vous vous êtes planté quelque part dans la config. En cas d’abandon de votre part, il suffit tout simplement de shooter le nginx et de remettre l’Apache sur le port 80 et ça sera reparti comme en 40 ! Si vous souhaitez apporter des corrections / précisions à ce petit tuto, n’hésitez pas !
A vous la toute puissance de l’internet rapide, le succès avec les femmes et un meilleurs référencement (oui car Google tient compte maintenant du critère de vitesse dans le référencement des sites)
Love !
Je vous recommande aussi la lecture des sujets suivants
- Jouer à Pong avec ses logs Apache
- Faire passer un script PHP par TOR
- Faille dans PHP < 5.3.1 – Comment patcher
- UwAmp – Le nouveau Apache, MySQL, PHP pour Windows
- La réécriture d’url pour les nuls
- Créer gratuitement et en quelques secondes un serveur proxy
- Android passe en open source… la fin pour Apple ?
- Internet pour tous 2/2
- Trouver des mots de passe avec Google
- Google as a free proxy
Hei Lian
« Mais si c’est du contenu statique », a priori c’est dynamique qu’il faudrait marquer là ^^
Bonne fête sinon :p
Posté le 24 décembre 2009 à 09:36:56
raph
le schéma ma fait trop rire!
Posté le 24 décembre 2009 à 09:38:39
Korben
@Hei Lian: oups, boulette ! merci
Posté le 24 décembre 2009 à 09:42:16
Avish
Sympa le schéma de la mort qui tue.
Au premier coup d’Å“il les performances, sont très proche de lighttpd
(voir un poil mieux).
Posté le 24 décembre 2009 à 09:52:27
gordontesos
Merci pour ce tuto extrêmement intéressant. Peux-tu expliquer le choix de Nginx par rapport à un lighttpd, par exemple ? Facilité de configuration ? Meilleures perfs ?
Posté le 24 décembre 2009 à 09:52:36
Korben
@gordontesos: C’est ce que tout le monde m’a recommandé. Après je ne sais pas si lighttpd est plus efficace que nginx. Faudrait faire ou trouver des benchmark.
Par contre, j’ai trouvé ça http://www.wikivs.com/wiki/Lighttpd_vs_nginx
a+
Posté le 24 décembre 2009 à 09:55:19
Aldarone
C’est clair comme explications et ça va me servir très bientôt (mon apache ayant quelques soucis avec certains proxy qui ne ferment jamais leurs connexions et en ouvrent une cinquantaine par seconde…)
Par contre, tu as une idée de la config à utiliser dans le cas où on utilise des virtual hosts avec apache ?
Posté le 24 décembre 2009 à 09:56:18
Foxrider
Pas mal du tout ces infos sur nginx. Je connaissais pas mais je met de côté, ca servira surement un jour ou l’autre !
Et je vais aussi aller jeter un oeil sur pencil ^^ Ca me parait bien prometteur !
Posté le 24 décembre 2009 à 09:58:09
Korben
@Aldarone: euh oui. J’utilise les virtualhost avec apache. T’as rien a changé dans la config apache à part le port.
Posté le 24 décembre 2009 à 10:00:40
Aldarone
Impeccable ! Dans ce cas je pense qu’avant la nouvelle année j’aurai mon petit nginx aussi
Posté le 24 décembre 2009 à 10:04:03
KetA
Une idée de la façon dont on déplace les uploads d’images de wordpress vers un sous-domaine ?
Posté le 24 décembre 2009 à 10:06:12
Marabok
« En effet, il peut en quelques minutes bouffer toute la mémoire de votre serveur et faire tourner le CPU à plus de 100 % ! »
Faire tourner un CPU à + de 100% c’est possible ça ? =o)
(non on parle pas d’overclocking
Posté le 24 décembre 2009 à 10:14:30
Korben
@Marabok: euh, ce qui est sûr c’est que quand je fais mon sudo top et que le serveur par en vrille, j’ai déjà eu des trucs genre 120% , 150% ! Donc c’est possible au niveau soft… après le cpu je ne crois pas non
Posté le 24 décembre 2009 à 10:17:03
Korben
@KetA: avec une petite regle de reecriture
Posté le 24 décembre 2009 à 10:20:00
Cricket
Un ptit coup de WP-SuperCache peut faire du bien aussi, si tu ne l’as pas installé
http://wordpress.org/extend/plugins/wp-super-cache/
Posté le 24 décembre 2009 à 10:31:36
Korben
@Cricket: si j’ai super cache aussi … Et sinon, memcached peut aussi s’interfacer avec tout ce basar… Mais faut voir si trop de cache ne ralenti pas le systeme. A tester
Posté le 24 décembre 2009 à 10:53:43
Lazarius
Pas mal du tout comme système, je vais penser à tester ça sur mon serveur apres les fêtes surement
Merci pour le schéma explicatif qui réveille ^^
Posté le 24 décembre 2009 à 11:20:04
Anis
Aller hop, dans mes signets !
Merci, ça pourra servir
Posté le 24 décembre 2009 à 11:35:49
if is Dead
Et si on sert plus de contenu dynamique que statique, ça va pas ralentir le tout ?
Parce que bon, ça rajoute une passerelle inutile entre apache et le visiteur tout ça.
Passer les images sur le port 8080 n’est il pas plus intéressant ?
Posté le 24 décembre 2009 à 11:55:46
Gusix
je pense que tu aurai pu tenter de remplacer ton apache par un lighttpd moins gourmand en ressources. Mais je met de coté. Merci
Posté le 24 décembre 2009 à 12:10:03
le hollandais volant
faire tourner le CPU Ã plus de 100 % ! Pas cool !
En effet !
Pour ça, c’est vrai qu’on est les méchants
Posté le 24 décembre 2009 à 12:18:08
Julien Tartarin
Sinon tu pouvais aussi configurer Apache en mpm worker (le comportement que tu décris c’est celui du mpm prefork), avec PHP en FastCGI, pour obtenir le même niveau de performance (voire mieux car sans intermédiaire), sans rien à changer sur ton site
Posté le 24 décembre 2009 à 12:23:04
Guillaume
Mettre phpmyadmin en direct sur internet tu n’as pas trop peur ?
en plus bien l’expliquer dans ta conf c’est un poil dangeureux pour moi
Posté le 24 décembre 2009 à 12:27:53
Dju
sympa ce p’ti tuto, merci pour l’explication je me demandais comment t’avais mis tout ça en place.
et btw, j’adoore tes schemas, ils ont le mérites d’être clairs, tout en me filant mal aux côtes :p
Posté le 24 décembre 2009 à 12:31:06
iMeee
Ah NGinx …
Moi j’utilise directement NGinx. C’est un très bon serveur web, stable, performant, etc … Il a toutes les qualités ! Deplus il fait reverse proxy, proxy mail (imap/pop etc …) et pleins d’autre choses. Pour le worker_processes c’est le nombre de processus, sa doit être égal aux nombre de CPU visible par ton OS. Sinon oui MemCached améliorerais bien les performances tout comme APC, eAccelerator, etc … (cache d’opcode). Et il y a des extensions WordPress toutes prêtes pour sa qui fonctionnent nickel !
Posté le 24 décembre 2009 à 12:37:16
trobert94
Tiens justement Korben, je voulais savoir si tu avais fait quelque chose pour rendre wordpress un peu plus rapide, parce que c’est quand même assez lourd comme truc.
T’as rajouté / modifié des trucs pour que ça aille plus vite ou c’est juste le serveur qu’est bon ?
Posté le 24 décembre 2009 à 12:45:24
Obidoub
Ben alors on te paye un serveur à 1700€ et c’est pas suffisant??
Posté le 24 décembre 2009 à 14:03:45
citoyenlambda
j’ai codé que dans de l’embarqué et dans les couches basses mais je trouve dingue qu’un process soit créé à chaque requète !
Je comprends que c’est plus efficace si quelqu’un envoie plusieurs requètes d’affilé mais pourquoi ne pas instaurer un contexte de session (utilisateur, adresse IP, port,…) dans un cache et rechercher dans ce cache lorsqu’une nouvelle requète se présente) ?
bon je dis ça j’ai réfléchis 3 secondes et j’ai jamais codé sur des hosts dans un système d’exploitation public et probablement que faire comme ça créerait des dépendances, mais puisque ton serveur ne fait que ça ça ne serait pas forcément génant (?).
Posté le 24 décembre 2009 à 14:17:14
Miroir
Ah ouais mais c’est d’ la triche, c’est pas d’ l’hébergement mutualisé
Et moi avec mes pages web où j’ai même pas le droit à du PHP ! XD LOL
Posté le 24 décembre 2009 à 14:21:09
kasi
Alors au final quel est l’ordre d’idée de gain de performance vu le commentaire : « Apache limite il s’enmerde »
?
Posté le 24 décembre 2009 à 14:37:12
titux77
Si y a plusieurs CPU, l’utilisation CPU pourra être supérieur à 100% (c’est le total de l’utilisation de tout les CPU).
Il vaut mieux regarder le load average pour savoir dans quel état est le serveur de ce coté, en gros ça permet de savoir si les ressources CPU commencent à être trop insuffisantes pour traiter la demande.
Ca aurait été pas mal d’avoir un comparatif nginx avec HAProxy et Squid pour cette utilisation de Reverse Proxy.
Posté le 24 décembre 2009 à 14:50:44
MSTRLO
Rien compris sauf le schéma ! <3 Schéma
Posté le 24 décembre 2009 à 15:07:10
foo
Pourquoi mettre la version 0.6.32?
Posté le 24 décembre 2009 à 15:30:53
iMeee
@foo:
Généralement sur un serveur en production on met une version stable …
Posté le 24 décembre 2009 à 16:16:22
Dju
p’tain il est rapide google, chez toi.
je tape « nginx » dans google, et ton site est deka
Posté le 24 décembre 2009 à 16:33:42
Dju
*deja la*
et testé avec du proxy et du php, ca marche plutôt bien et consomme effectivement bien moins qu’apache…
que du bon
Posté le 24 décembre 2009 à 16:34:24
Jérôme
Pas mal le schéma
tant qu’à continuer l’optimisation, 93 requêtes sont effectuées pour afficher cette page dont 10 + 1 sharethis pour les CSS et 12 + 1 sharethis pour le JS, en fusionnant les 10 CSS dans un seul fichier et de même pour le JS, tu économises 20 requêtes soit 20%.
Une utilisation des sprites CSS pour les 6 petites images du header ( http://css-tricks.com/css-sprites/ ) économiserait 5 requêtes.
Et pour finir, passer tout ça sous le sous-domaine pictures.* (délivré par NginX) et enlever le reverse proxy puisqu’il ne reste plus que le contenu dynamique délivré par Apache.
That is just my 2 cents
Posté le 24 décembre 2009 à 16:41:56
John Smith
Finalement on se décide à utiliser nginx
Il était temps !
Et Jérome à raison, il y a grand intérêt à servir tout ce qui est statique par nginx directement (images du blog, js, css…etc)
Bon, prochaine étape : virer Apache pour de bon et passer à du 100% NGINX + PHP-FPM.
Regarde aussi du côté de cherokee pour le contenu dynamique qui assure à mort.
http://www.cherokee-project.com/
Posté le 24 décembre 2009 à 19:03:30
Alkpone
Pourquoi pas lighttpd qui gere php avec fast-cgi ?
Posté le 24 décembre 2009 à 20:19:50
Dju
@Alkpone: meme si LightHttpd est plus léger qu’apache, il a pas mal de memory leaks. du coup il faut le redemarrer systematiquement au bout d’un certain temps…
@John Smith: php-fpm est il mieux que php-fastcgi ?
car apres avoir testé nginx+php-fcgi, à utilisation égale, apache est plus gourmand.
Mais étant plus léger, il a aussi pas mal de fonctions en moins par rapport à apache. Donc un remplacement total est difficilement envisageable avec un blog/php type wordpress/dotclear qui fait de l’url-rewriting conditionnel etc…
Par contre en tant que reverse-proxy frontal devant apache, ca roxe bien
Posté le 24 décembre 2009 à 20:32:09
John Smith
@Dju: PHP-FPM est juste une sorte de patch pour PHP-FCGI..et oui, c’est beaucoup plus efficace d’utiliser PHP-FPM couplé à NGINX plutôt que NGINX et le spawn fcgi de lighty (truc habituel connu des utilisateurs d’nginx).
Perso, ce que j’utilise c’est cherokee + fcgi et nginx en reverse proxy qui sert également le contenu statique.
Cherokee est extrêmement puissant et les possibilités sont presque infinies, il est aussi très léger, et très très configurable.
La configuration peut se faire à partir d’un interface d’administration, et il y a des règles pré-configurés pour wordpress, et tout les CMS connus.
Cherokee vaut largement NGINX Ã mon avis quand il sagit de PHP.
Par contre il est inférieur pour ce qui est statique
A+
Posté le 24 décembre 2009 à 22:00:47
PapyGeek
@Korben: sinon je donne un ptit tuyau comme ça : comme Nginx est super fort pour servir les fichiers statiques, et comme wp-supercache génère des fichiers html (statiques donc), pourquoi ne pas les servir directement avec nginx ?
C’est ce que je fais sur papygeek.com, et ça gère.
Pour ceux que ça intéresse, j’avais aussi parlé d’nginx il y a quelques temps ici : http://www.papygeek.com/software/optimiser-son-serveur-web-avec-nginx/
Je referais peut-être un petit article pour expliquer ma conf de maintenant.
Posté le 24 décembre 2009 à 23:57:08
Eno
Pour ceux qui veulent vraiment optimiser leur site, je vous conseil de regarder Varnish
Posté le 25 décembre 2009 à 02:31:10
Maxence
@if is Dead utiliser un port différents que le 80 pour le web n’est pas une bonne idée, car souvent dans les grosse boite si par chance le port 80 est ouvert c’est malheureusement tout ce qui y a avec le port 25
Sinon pour éviter cette passerelle comme tu dis, si korben à au moins 2 ip sur sa machine, il peut très bien utiliser picture.korben.info avec une autre ip (celle qu’nginx écoutera) que celle de http://www.korben.info et tous ça sur le port 80
Pour ma part j’utilise apache pour php et lighttpd pour les images,scripts et autre fichier qui changent très rarement et aussi pour faire du pseudo streaming vidéo, pratique pour proposer à ses visiteur du streaming vidéo à bas cout quand on héberge ses propres vidéos. (mais je crois qu’apache dispose d’un module pour ça maintenant)
Posté le 25 décembre 2009 à 03:28:56
foo
@iMeee: la 0.6.39 est stable ainsi que la 0.7.64
Posté le 25 décembre 2009 à 15:28:09
John Smith
@foo: Comme tu peux le voir dans le post de Korben, il a choisi de ne pas compiler NGINX par la source, et a décidé de l’installer par les packages debian/ubuntu (je sais pas quelle distrib il a) où la version stable est la 0.6.32.
La 0.7.64 est « unstable » dans les packages
Posté le 25 décembre 2009 à 15:56:44
laurentgina
Très bon article Korben,
Aurais tu des solutions pour améliorer la bande passante?
Posté le 25 décembre 2009 à 16:36:19
Eno
@laurentgina:
- Optimiser ton code
- Optimiser les images
- Striper les infos dans les images
- Utiliser la compression pour le transfert ( gzip ect … )
Posté le 25 décembre 2009 à 18:35:11
glop78
Hello
Est il possible de faire ce type de config avec un dédié comportant plusieurs domaines ?
La le proxy pointe direct vers 10.0.0.1:8080 donc en gros la racine du serveur niveau http
Posté le 25 décembre 2009 à 18:41:16
Henry cow
Ceux qui ont testé, ça peut booster une vieille Dédibox ce proxy?
Posté le 25 décembre 2009 à 19:59:43
John Smith
@glop78: oui, pas besoin de toucher aux virtuals hosts d’Apache (ou de n’importe quel autre HTTPD)
Dans l’exemple de Korben, t’as juste a ajouter tes domaines à la suite :
server_name korben.info tondomaine1.com tondomaine2.net;
Il pointeront tous vers ton serveur HTTPD qui se trouve derrière nginx et qui se chargera des vHosts
@Henry cow: Le mieux pour booster une vielle dedibox serait de mettre Apache au placard, et d’opter pour un « vrai » serveur HTTPd (cherokee ou nginx sont très performants en php-cgi) et tu verra qu’un httpd qui consomme 100+ Mo de RAM n’est pas normal (contrairement à ce à quoi Apache nous a habitué)
Posté le 25 décembre 2009 à 23:29:03
Korben
Merci pour vos conseils supplémentaires les gars !! Je vais lire tout ça au calme
Posté le 26 décembre 2009 à 09:23:03
DjinnS
Tu devrais déjà configurer Apache correctement, PHP correctement et MySQL correctement avant d’aller raconter des conneries.
Apache en worker avec PHP sera toujours plus lent que le prefork avec PHP en module (pour le commentaire qui en parle). Bench à l’appui.
Si tu veux du proxy, prends un vrai proxy comme Squid ou Varnish, là tu auras plus de performances pour tes fichiers statiques. Mais bon, des apache qui crache 20x plus de page que ton site ça existe (j’en ai) pas besoin de kikouloler avec Nginx.
Et utilise un opcode, ça sera déjà mieux si c’est pas déjà le cas.
Posté le 26 décembre 2009 à 14:13:35
John Smith
@DjinnS: t’es marrant toi.
Pour ce qui est des proxy, Squid est pourri…
Varnish est pas mal avec son système de cache « intelligent » mais par contre pour les fichiers statiques, il est infiniment mieux d’utiliser nginx (qui est le moyen le plus rapide de les servir connu par l’Homme).
Voir aussi nCache : http://code.google.com/p/ncache/ qui est l’équivalent de Squid/Varnish basé sur le code du serveur russe
Après en PHP, Apache sera surement un peu meilleur qu’NGINX avec un nombre élevé de connexions (et encore), mais quand on voit les ressources qu’il consomme, il y a de quoi flipper.
)
Puis Korben.info, c’est beaucoup de statique puisque des fichiers .html sont générés par WP-Super Cache. (d’ailleurs je trouve que W3 Total Cache est mieux
Donc mieux vaut les servir également avec nginx, ainsi que le css, les images du thème et le js.
L’intérêt d’un reverse proxy est également de bien mieux contrôler le trafic qui arrive et de protéger le serveur backend (à condition d’avoir un autre serveur) en cas de DOS ou autre (nginx encaisse à max)
Enfin bon, je pense pas pouvoir convaincre les inconditionnels d’Apache…C’est un peu une peine perdu :/
Posté le 26 décembre 2009 à 15:13:17
Eno
Apache est bien il faut juste le tuner et avoir un loadbalancer / reverse proxy devant et un serveur pour le contenu statique
Posté le 26 décembre 2009 à 17:26:05
Alain Ternaute
Bonjour.
Pour faire de bô schémas (réseau ou autre), on peux aller sur http://my.lovelycharts.com/ on se fait un compte gratos et c’est bon.
Schémas exportables en PNG (ou JPG si on ne veut pas de transparence). Je précise juste qu’en compte free, on à le droit qu’à un seul schéma sauvegardé (zut !).
Dans le même genre, il y à Gliffy : http://www.gliffy.com/ mais je n’ai pas test.
Posté le 26 décembre 2009 à 20:53:46
DjinnS
Je dois être marrant, sans doute, mais tu devrais toi aussi apprendre à configurer Squid avant de cracher dessus. T’être même regarder un coup du coté des headers HTTP, t’être, non ? Squid peut cracher 2K pages/secondes, sans forcer. C’est sur, c’est pourri …
Le mode reverse de ngnix n’a pas toutes les possiblités de Squid.
Ngnix tient-il compte des headers cache-control ? Utilise-t-il un algo pour maintenir les objets hot en mémoire ? Etc .. etc … Squid le fait.
Varnish est sympa mais est très contraignant pour l’admin, puisqu’il doit se taper les règles et bien connaitre donc l’application. Ce qui est généralement du domaines des devs, mais comme c’est des quiches … Il est parfois préférable de leur prendre la tête avec les headers cache-control et les laisser gérer la cache … Varnish est jeune mais il est certain qu’un jour, il sera bien supérieur à Squid.
Bref, ici on ne parle pas de proxy mais d’un vieux proxy-pass à la apache pour balancer trois images. Rien d’extraordinaire et certainement pas la configuration ultime pour la performance, bien au contraire.
Posté le 27 décembre 2009 à 00:39:48
foliop
@John Smith: Justement c’est ce que j’ai fait mais ca pointe directement à la racine du serveur
Posté le 27 décembre 2009 à 11:15:55
arteta
@DjinnS:
Plutôt d’accord avec toi, sauf sur le ton utilisé
Sinon nginx intègre un cache (en proxy ou fastcgi via phpfpm par exemple) depuis la version 0.7.48:
=> http://wiki.nginx.org/NginxHttpProxyModule#proxy_cache
Ça marche plutôt bien.
Pour mon taff, j’ai utilisé Varnish, et j’ai vraiment été charmé, l’idée de pv faire des règles style: navigateur <> cache, backend <<>> cache, est juste génial, genre j’ai mi en place une politique de cache assez rapidement (en cache tout, si le cookie de session est seté, on pipe).
Pour finir, plutôt propre de réduire les threads prefork apache uniquement pour le php, pas si con que ca, et nginx délivre bien plus rapidement le static (jpeg, css, js, and co).
Posté le 27 décembre 2009 à 18:53:54
Frédéric de Villamil
Hmmm je vais faire mon chieur, comme d’hab, mais je ne vois pas tellement à quoi ça sert…
En gros :
Ton Apache n’en a rien à foutre de servir du fichier statique, pas plus que ton nginx. Ton goulet d’étranglement se trouve au niveau de (cette merde de) WordPress et des plugins que tu utilises, donc du dynamique. Poser un Nginx en reverse proxy n’a d’intérêts que si
– tu as plusieurs serveurs applicatifs pour servir ton dynamique (exemple, nginx + des fastcgi servers pour ton WordPress auquel cas adieu Apache. C’est ce que j’ai mis sur mon infra.
– tu as plusieurs machines physiques ou virtuelles qui te servent le PHP / les assets.
En fait, je serais toi, je testerai nginx avec plusieurs worker, du PHP fastcgi, le wp-supercache posé sur du memcache histoire d’accélérer les i/o.
Mais ça ne résoudra pas le problème principal : WordPress et ses plugins à la con.
Posté le 27 décembre 2009 à 21:06:00
Eno
@Frédéric de Villamil: Y’a aussi le fait que Apache est très vulnérable aux attaques de type DoS et gère très mal un haut trafic si il est tout seul.
Donc bon c’est pas vraiment inutile.
Posté le 28 décembre 2009 à 15:45:53
Gilles
Sympa
Posté le 29 décembre 2009 à 09:28:07
Nicolas Chevallier
Merci pour ce tutorial, je cherchais justement des infos sur nginx car j’ai aussi mon pauvre serveur qui chauffe.
Posté le 29 décembre 2009 à 17:21:45
Frédéric de Villamil
@Eno:
Hmmm WTF comme ils disent ? Je ne vois pas tellement le rapport entre :
La vulnérabilité d’Apache à un type de déni de service basé sur la manière dont Apache gère les fins de connexion, provoqué par des paquets forgés.
La manière dont Apache gère les fichiers statiques (en l’occurrence parfaitement)
Le fait que WordPress soit une usine à gaz mal foutue mettant régulièrement le serveur de Korbenichou à genoux parce que le très grand nombre de commentaires et de visites rend la mise en place d’un cache parfaitement caduque sur ce dernier.
Je te propose donc un truc : je monte un apache sur une machine de type Dedibox de base, pour lui faire servir des assets, et uniquement des assets. Et on lance un bench genre 10000 connexions par seconde sur ces ficihers statiques pendant quelques heures. Et on voit comment il tient.
Posté le 30 décembre 2009 à 21:08:29
if is Dead
@Maxence: Merci beaucoup pour ta réponse
Je n’avais jamais songé que je pouvais faire varier le traitement du port 80 sur un même serveur qui aurait deux ips.
Vu qu’OVH fourni des IP fail over, je suppose que c’est une solution efficace pour faire la même chose que propose Korben sans pour autant avoir d’intermédiaire…
Enfin, il me reste plus qu’Ã trouver comment
Posté le 30 décembre 2009 à 23:32:35
if is Dead
Je m’auto réponds au cas où ça intéresse quelqu’un:
si vous voulez faire ce que Korben fait mais sans passer par l’intermédiaire de Nginx en ce qui concerne le contenu dynamique (donc aucune passerelle entre le visiteur et apache):
il vaut faut un serveur avec deux ip (ip fail over d’ovh par exemple)
ip1 : vous configurez votre DNS du www pour pointer dessus
ip2 : vous configurez votre DNS de images pour pointer dessus (ou bien static)
Dans la config apache vous mettez :
Listen ip1:80
NameVirtualHost ip1:80
DocumentRoot /www/
ServerName http://www.mondomaine.com
Puis, sous nginx (pas encore cherché) ou bien lighttpd (pas cherché non plus), il suffit de faire l’inverse en écoutant ip2:80.
Enfin, j’ai pas encore testé
Posté le 31 décembre 2009 à 12:56:30
Le blog à Dju
Installer Ubuntu Server sur le zotac mag…
Aujourd’hui au programme, installer ubuntu server 9.10 Mon ami ayant eu à nouveau besoin de son lecteur dvd usb, il nous faudra passer par la clé USB. Pour cela, il vous faudra un autre ordinateur, déjà sous ubuntu, afin de formater la clé usb et de l…
Posté le 3 janvier 2010 à 15:22:14
Liens en vrac – 10 | Jérémy Verda's blog!
[...] Korben a écrit un tuto pour mettre en place un Reverse Proxy Nginx sur son serveur. [...]
Posté le 3 janvier 2010 à 15:31:12
Friendly Froggy ;-) » Les solutions de reverse cache proxy pour pallier aux problèmes de cache
[...] Intro et configuration (Korben) [...]
Posté le 13 janvier 2010 à 14:13:18
Toto
Bonjour.
Je trouve Cherokee très interessant, surtout avec l’interface web d’administration.
Les benchs sont aussi en sa faveur.
John Smith : tu sembles très bien t’y connaître pour Cherokee : STP, pourrais-tu m’indiquer comment l’installer et le configurer efficacement sur un VPS (Xen, 256MB) Ubuntu server 9.10?
L’un des problèmes résidera en l’utilisation des .htaccess et des rewrite d’Apache : comment l’as-tu contourné?
Merci d’avance.
Posté le 17 mars 2010 à 17:04:22
Toto
@John Smith: Un tuto détaillé sur Cherokee serait le bienvenu.
Merci d’avance.
Posté le 17 mars 2010 à 17:07:39
[Tutoriels] Configuration de Nginx en reverse proxy | Bastien Louche
[...] Sources et Informations supplémentaires : [1] [2] [...]
Posté le 31 mars 2010 à 17:31:26
Comment optimiser un blog Wordpress quand on est sur un serveur dédié ? | AbriCoCotier.fr
[...] laisser à Apache que la gestion de la génération du code et de donner à un serveur plus rapide (nginx ou lighthttpd par exemple) la gestion des fichiers statiques, qui composent la large majorité (en [...]
Posté le 7 avril 2010 à 12:59:15