Mettez un turbo dans votre serveur web avec NginX
Le serveur web Apache reste le serveur d’application http de premier choix pour le PHP5, du fait de sa grande fiabilité, de son ancienneté, et de ses performances éprouvées y compris pour des fortes charges sur des serveurs de production en environnement distribué. Sa grande sophistication et la complexité de certaines configurations utilisant de nombreux modules optionnels en font en revanche un grand consommateur de mémoire RAM, ce qui est moins problématique qu’auparavant sur des serveurs modernes. Il reste qu’Apache en solo n’est désormais plus la meilleure solution pour des sites web pour lesquels les performances ultimes sont recherchées. Je vous propose ici une architecture combinant Apache, eAccelerator et NginX sur un même serveur dédié qui apporte un excellent rapport performances/simplicité de maintenance et d’installation.
NginX, le serveur venu de l’Est
Est-il encore besoin de présenter NginX, le serveur “léger et rapide” développé par le russe Igor Sysoev ? Cet outil fait partie d’une gamme de serveurs web ultra-optimisés (le concurrent le plus connu est lighttpd) qui ont révolutionné les architectures de plateforme d’hébergement web depuis quelques années, et viennent souvent bousculer le monopole d’Apache 2. Leurs atouts sont une empreinte mémoire réduite au minimum, et une gestion simplifiée des processus dont la philosophie est de servir au plus vite chaque requête pour éviter d’avoir à gérer un parallélisme trop gourmand en charge système et en mémoire RAM.
Quand il s’agit de servir les fichiers “statiques” (images, feuilles de style CSS, fichiers javascript,…) qui constituent la grande majorité des requêtes http que reçoit un serveur web typique, les serveurs web “légers” sont imbattables.
Le meilleur des deux mondes
Je garde une préférence pour Apache2 en matière de serveur d’application PHP5 avant tout parce que j’apprécie ses possibilités d’optimisation très fines, la diversité des modules disponibles, et aussi parce qu’il s’agit pour moi d’une solution très largement éprouvée, que j’ai vu fonctionner de façon fiable sous de très fortes charges et dans des environnements très divers, couplé au cache d’opcode eAccelerator.
Même si les derniers développements de modules php5 pour NginX viennent rivaliser avec les performances d’Apache selon certaines études, j’ai tendance à faire confiance à l’outil qui a fait ses preuves et que je connais le mieux. Il faut également noter que la gestion des règles de ré-écriture par le module rewrite, et l’utilisation des fichiers de configuration distribués (mécanisme .htaccess) comptent parmi les atouts indéniables d’Apache. Enfin, la documentation disponible sur le web est bien pus vaste pour Apache que pour tous ses concurrents plus récents, encore trop peu répandus pour bénéficier du même engouement dans les communautés en ligne.
Il y a cependant moyen d’améliorer énormément les performances d’une plateforme d’hébergement web sous Apache en la couplant avec un serveur NginX qui agit comme frontal en traitant directement les requêtes qui concernent les fichiers statiques, mais passe la main à Apache pour le traitement des fichiers dynamiques (PHP), en jouant le rôle d’un reverse proxy (serveur mandataire inversé).
Voici comment procéder.
Installation de la plateforme LAMP
Se référer à mon guide de configuration pas-à-pas d’un serveur LAMP sous Debian 6 pour toute la configuration du système depuis le partitionnement jusqu’à l’installation des services de monitoring. Pour simplifier la suite de la configuration, l’installation d’Apache, du module PHP5 pour Apache et du cache d’opcode eAccelerator doit avoir été faite préalablement, et testée. Mon guide de compilation et mise à jour d’eAccelerator est ici. Mon guide de configuration d’Apache est ici.
Installation de NginX sous GNU/Linux Debian
L’installation du serveur web NginX se fait le plus simplement du monde à partir des paquets Debian :
apt-get install nginx
Puisque Apache est déjà présent et configuré pour “ecouter” sur le port http par défaut, NginX ne peut pas démarrer correctement comme on peut le constater en tentant de le relancer :
/etc/init.d/nginx restart
Restarting nginx: [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [emerg]: bind() to [::]:80 failed (98: Address already in use) [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [emerg]: bind() to [::]:80 failed (98: Address already in use) [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [emerg]: bind() to [::]:80 failed (98: Address already in use) [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [emerg]: bind() to [::]:80 failed (98: Address already in use) [emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [emerg]: bind() to [::]:80 failed (98: Address already in use) [emerg]: still could not bind() nginx.
Nous allons remédier ce problème en reconfigurant Apache, puis NginX.
Re-configuration d’Apache
sudo vi /etc/apache2/ports.conf
->
NameVirtualHost *:8080 Listen 8080
On demande à Apache de ne plus “écouter” sur le port TCP par défaut pour http (80), mais de répondre sur le port 8080 afin de libérer le port 80 pour NginX. NginX passera les requêtes qui le concernent à Apache via ce port 8080.
sudo vi /etc/apache2/sites-enabled/000-default
-> <VirtualHost *:8080>
On indique également à la configuration du serveur web par défaut que c’est désormais le port 8080 qu’il faut servir.
sudo /etc/init.d/apache2 restart
-> Si vous faites un test de connexion http, le serveur Apache ne répond plus. Il répond maintenant sur le port 8080 (http://<votre_serveur>:8080/)
NB : nous autorisons Apache à répondre à toutes les requêtes extérieures pendant la phase de configuration et de tests, mais en configuration de production il faudra restreindre cet accès en indiquant à Apache de ne répondre qu’à des requêtes “locales” issues de l’adresse localhost (127.0.0.1) – car le seul flux autorisé arrivera de NginX qui joue le rôle de mandataire pour toutes les connexions http.
Configuration de NginX
Si on redémarre NginX avec la configuration par défaut, il va maintenant pouvoir démarrer correctement (le port 80 est libéré par Apache), et se mettre à répondre :
sudo /etc/init.d/nginx restart
http://<votre_serveur>
Si on observe le header de réponse renvoyé par le serveur (par exemple avec la “Web Developer Toolbar” pour Firefox ou Chrome/Chromium), on vérifie que c’est maintenant bien NginX qui répond sur le port 80 :
Date: Fri, 20 May 2011 08:57:01 GMT Content-Encoding: gzip Last-Modified: Thu, 19 May 2011 20:26:11 GMT Server: nginx/0.7.67 Content-Type: text/html 200 OK
Alors que c’est Apache qui répond sur 8080 :
http://<votre_serveur>:8080
Date: Fri, 20 May 2011 08:52:17 GMT Content-Encoding: gzip Content-Length: 146 Last-Modified: Thu, 19 May 2011 20:26:11 GMT Server: Apache ETag: "880002-b1-4a3a6d0debec0" Vary: Accept-Encoding Content-Type: text/html Accept-Ranges: bytes 200 OK
Nous allons maintenant adapter la configuration de NginX pour lui faire jouer les deux rôles qui nous intéressent, à savoir servir directement les fichiers statiques le plus vite possible, et passer toutes les autres requêtes à Apache en jouant le rôle de frontal. Au passage nous ferons quelques réglages sur la configuration par défaut de NginX.
sudo vi /etc/nginx/nginx.conf
-> worker_processes 2;
(augmente le parallélisme pour les serveurs multi-processeurs soumis à de fortes charges. Modification inutile sur des serveurs dont la charge est faible, qui sont très rapides ou qui n’ont qu’un processeur… il faut expérimenter pour juger de l’utilité ou non d’augmenter le nombre de processus parallèles. Régler ce chiffre sur le nombre de processeurs est une bonne option en général.)
Pas d’autre modification sur la configuration par défaut de NginX.
Servir directement les statiques
sudo vi /etc/nginx/sites-enabled/default
Ajouter la directive location suivante vers le haut du fichier : elle indique que tous les fichiers statiques doivent être servis directement par NginX à partir du répertoire racine du site web (/var/www par défaut) en ajoutant l’en-tête expires avec un délai de mise en cache par le navigateur d’un an (365 jours), et en désactivant la journalisation (on s’intéresse rarement au nombre d’images vues sur un site, les métriques importantes étant plutôt le nombre de pages vues et le nombre de visiteurs).
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www;
expires 365d;
access_log off;
}
Mode reverse-proxy pour les fichiers PHP
Remplacer la directive location responsable du traitement par défaut (on a commenté les deux lignes qui figurent par défaut dans cette directive et ajouté les nôtres à la suite) :
location / {
#root /var/www;
#index index.html index.htm;
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
}
Cette directive indique à NginX que par défaut, tous les types de requêtes qui n’ont pas été interceptés par la première directive ci-dessus (donc toutes les requêtes à l’exception des fichiers identifiés comme statiques) doivent être passées à Apache sur le port local 8080 en mode proxy. Au passage, on ajoute l’en-tête Host qui permettra à Apache de savoir à quelle adresse est destinée la requête (important dans le cas où on a plusieurs virtual hosts). On ajoute également les entêtes “Real IP” et “Forwarded for” pour permettre à Apache de retrouver l’adresse IP d’origine du visiteur (voir ci-dessous). Là non plus, on n’effectue pas de journalisation, car on laissera cette tâche à Apache (inutile de logger de façon redondante les mêmes visites !).
Ajouter enfin cette directive, afin d’optimiser la façon dont les navigateurs web mettront les pages en cache :
add_header Cache-Control public;
…c’est tout pour la configuration de NginX.
sudo /etc/init.d/nginx restart
-> On peut tester que les fichiers PHP sont bien exécutés, par exemple :
http:<votre_serveur>/my_phpinfo.php (traité par Apache comme on peut le voir en vérifiant les en-têtes http)
…par contre, phpinfo() nous indique toujours dans la variable d’environnement REMOTE_ADDR que l’adresse IP du visiteur est toujours celle du proxy local NginX (127.0.0.1). Idem dans les logs Apache. Nous allons maintenant remédier à ce problème.
Récupérer l’adresse IP d’origine côté Apache avec mod-rpaf
Le module pour Apache RPAF (Reverse Proxy Add Forward) s’occupe de récupérer l’information passée par NginX via l’en-tête X-Forwarded-For pour que les autre modules Apache (dont le PHP) “voient” l’adresse du visiteur d’origine, et pas l’adresse du serveur proxy (127.0.0.1).
Il s’installe très facilement sous Debian 6 :
sudo apt-get install libapache2-mod-rpaf
Normalement, l’installation automatique du paquet Debian va rajouter la configuration nécessaire pour Apache dans le fichier /etc/apache2/mods-enabled/rpaf.conf. Si ce n’est pas le cas, vous pouvez modifier vous-même la configuration du virtual host d’Apache afin d’indiquer les adresses des passerelles mandataires (proxies).
sudo vi /etc/apache2/sites-enabled/000-default
Ajouter les lignes suivantes ( uniquement si elles ne sont pas déjà présentes dans /etc/apache2/mods-enabled/rpaf.conf ) :
<IfModule mod_rpaf.c> RPAFenable On RPAFsethostname On RPAFproxy_ips 127.0.0.1 </IfModule>
Redémarrer le serveur Apache :
sudo /etc/init.d/apache2 restart
…le tour est joué, si on vérifie par exemple avec phpinfo(), on remarque que dans la section “Apache Environment“, la variable “REMOTE_ADDR” indique maintenant l’adresse IP réelle du visiteur, et plus l’adresse 127.0.0.1 comme auparavant. Le système de proxy NginX est donc devenu dans les faits “invisible” pour Apache. Notre configuration est bouclée. Nous sommes passés au moteur hybride !
Liens utiles
- Configuration d’Apache pour l’utilisation de la mémoire et les performances
- NginX How To (en anglais – avec de nombreux exemples)
- NginX proxying to Apache install guide @Joyent (en anglais)
- NginX http core directives (en anglais)
- Module NginX httpProxy (en anglais)
- NginX as a reverse proxy (en anglais)
- En-tête http Cache-Control sur Wikipedia (en anglais)
- NginX and Cache control directive (en anglais)
- NginX log request speed (pas utilisé ici mais utile pour l’optimisation de performances – en anglais)
- Un exemple de configuration NginX (serveur polonais !)
- RPAF : site web officiel du module
- Package Debian RPAF
le 20 May 2011 à 12:19 h
[...] Il s’agit au départ d’un memento qui me sert à “remonter” rapidement une configuration opérationnelle sous Debian 6 / Apache2 / PHP5 / Mysql pour héberger des sites sur un serveur dédié GNU/Linux type OVH ou Kimsufi. Cette configuration, qui inclut également eAccelerator et des outils de supervision et d’administration de base (Munin, phpsysinfo, mytop, PhpmyAdmin, AWStats) est opérationnelle et suffisamment sécurisée pour une installation standard (à condition de faire régulièrement toutes les mises à jour des packages). Par ailleurs, une extension de ce guide expliquera comment y ajouter un serveur Nginx configuré en frontal (reverse proxy) pour optimiser et accélér…. [...]
le 20 May 2011 à 16:19 h
[...] – Installer un serveur web léger en parallèle d’Apache pour traiter toutes les requêtes “statiques” qui ne nécessitent pas de charger le moteur d’application PHP. Lire à ce sujet mon article sur le “moteur hybride” PHP + NginX. [...]
le 20 May 2011 à 21:18 h
[...] Soulager Apache et augmenter les performances en le couplant avec NginX [...]
le 19 July 2011 à 13:56 h
donc oui un bon sujet !! un truc a faire !!
mon seul probléme je voudrais bien savoir qui gére les site internet apache ou NginX au niveaux des virtualhost
??
le 19 July 2011 à 14:10 h
La plupart du temps, NginX est en frontal sur tout, il reçoit toutes les requêtes http indépendamment des virtualhosts, et passe tout ce dont il ne s’occupe pas directement à Apache. La configuration des virtual hosts reste donc dans Apache. Par exemple, NginX ne s’occupera que des images d’un site, tout le reste (autres sites), il le passera à Apache de façon transparente.
Côté NginX on peut cependant définir des règles différentes en fonction des adresses demandées aussi. Dans ce cas on a deux configurations à gérer : celle de NginX et celle d’Apache. Dès qu’il y a plus de deux ou trois sites sur le même serveur physique ça risque de devenir nécessaire car il sera trop compliqué de gérer toute la config NginX au même endroit. Les virtual hosts seront donc géré en double, dans les deux configurations, qui devront correspondre. En tout cas NginX ne peut pas lire les fichiers de configuration d’Apache et réciproquement.
le 25 July 2011 à 21:25 h
bonsoir,
merci pour vos tutoriels!
permettez-moi de vous soumettre un problème:
- j’ai un petit Kimsufi qui héberge mon site web.
- j’ai un serveur de fichier ailleurs, dont la vitesse de connexion est pas géniale.
- lorsqu’un visiteur demande à télécharger un fichier, mon Kimsufi récupère le-dit fichier depuis le serveur de fichier (en http, avec un wget dans mon fichier php…) et permet au visiteur de télécharger ce fichier après quelques minutes.
problème: ce rapatriement peut être assez long, et pour l’écourter je souhaiterais que le visiteur puisse initier son téléchargement AVANT même que mon Kimsufi l’ai lui-même récupéré en entier.
en gros mon Kimsufi ce serait un intermédiaire qui récupèrerait un flux de données (issu de serveur qui stock mes fichiers) et qui le transmettrait aussitôt à celui qui l’a demandé, plutôt que de stocker ce flux progressivement pour former le fichier et enfin le servir (trop long…).
C’est ainsi que je suis tombé sur votre blog! avec les mots clés “nginx” puis “reverse proxy” et “http tunneling” entre autres! je ne sais pas comment on appelle ce que je souhaite mettre en place mais avec votre article je crois approcher du but, il me manque juste quelques pistes!
merci à vous.
le 26 July 2011 à 12:44 h
@Musa:
Ce que vous décrivez est bien une sorte de serveur mandataire (proxy en anglais). Vous pouvez simplement utiliser un des utilitaires de serveurs proxy courants spécialisés dans ce type de tâches (Squid, Varnish), ou utiliser un serveur web en mode proxy (Apache ou NginX). S’il y a déjà Apache sur votre Kimsufi, ajoutez-y simplement le mod_proxy, et configurez-le pour servir le contenu de votre autre serveur (il peut même le récupérer en FTP !). Voir ici : http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
le 26 July 2011 à 13:12 h
merci à vous!
le 30 July 2011 à 15:01 h
bonjour,
quid du multi-domaine et des sous-domaines?
si j’héberge par exemple un site1 avec sous-domaine dans mon repertoire tel que /var/www/site1.com/sd/blog
alors dans ce cas:
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www;
expires 365d;
access_log off;
}
ne fonctionne pas.
il me faut remplacer par:
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www/site1.com/sd/blog ;
expires 365d;
access_log off;
}
afin que les contenus statiques soient bien rendus par nginx lorsque je me rends sur blog.site1.com
sauf qu’ainsi, bien que blog.site1.com fonctionne désormais à merveille avec cette petite correction, qu’en est-il de site2.fr, localisé dans /var/www/site2.fr/ ??
faut-il réécrire une règle “location ~*” pour chaque site? comment?
amicalement,
le 30 July 2011 à 15:03 h
bonjour,
encore moi!
quid du multi-domaine et des sous-domaines?
si j’héberge par exemple un site1 avec sous-domaine dans mon repertoire tel que /var/www/site1.com/sd/blog
alors dans ce cas:
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www;
expires 365d;
access_log off;
}
ne fonctionne pas.
il me faut remplacer par:
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www/site1.com/sd/blog ;
expires 365d;
access_log off;
}
afin que les contenus statiques soient bien rendus par nginx lorsque je me rends sur blog.site1.com
sauf qu’ainsi, bien que blog.site1.com fonctionne désormais à merveille avec cette petite correction, qu’en est-il de site2.fr, localisé dans /var/www/site2.fr/ ??
faut-il réécrire une règle “location ~*” pour chaque site? comment?
amicalement,
le 23 August 2011 à 15:02 h
Salut,
J’ai pas compris ou tu mettais le add_header Cache-Control public;
Dans la directive location par défaut ?
Merci,
Jérôme
le 23 August 2011 à 15:25 h
@Jerome :
Non, la directive
add_header Cache-Control public;
vient directement dans le bloc
server { … }
au premier niveau.
le 27 September 2011 à 15:50 h
Bonjour Yann et merci pour ce tuto.
Je l’ai suivi et tout marche a merveille pour mon répertoire /var/www, c’est à dire le site en lui-même.
En revanche, dès que j’attaque un répertoire du site ou un allias (/phpmyadmin, /munin, /phpbb etc…) il se rajouter un :8080 qui me gène.
Peux-tu me dire comment masquer ce port 8080 dans les allias et les sous-répertoires, afin que ca ne gène pas la navigation des utilisateurs ?
J’ai essayer de jouer avec les directives dans le fichier /etc/nginx/sites-enabled/default mais ans succès.
Merci beaucoup.
Cordialement,
Seb
le 25 January 2012 à 18:02 h
Excellent tutoriel, complet et très clair.
Vitesse accrue, avec un RAM allégé! c’est vraiment parfait.
le 16 February 2012 à 13:06 h
Bonjour,
Excellent tutoriel.
Cependant, j’ai un soucis.
J’ai un comportement inverse : les demandes de pages php renvoient en tant que header nginx alors que les pages html renvoient un header de Apache.
Voila mon fichier
server {
listen 80; ## listen for ipv4
listen [::]:80 default ipv6only=on; ## listen for ipv6
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www;
expires 365d;
access_log off;
}
location / {
#root /var/www;
#index index.html index.htm;
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
add_header Cache-Control public;
}
location /doc {
root /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}
D’avance merci pour l’aide apportée
le 16 February 2012 à 16:11 h
@Maxime : c’est probablement un problème de préséance entre les différentes directives location… mais il faudrait un diagnostic plus poussé pour en être sur.
le 21 February 2012 à 3:22 h
Salut, intéressant ton article.
Cependant j’ai une petite question…
Dans le cas de fichiers statiques traités par un rewriting, genre /icons/icons.png qui en fait ne se trouve pas à la racine du site mais dans un sous répertoire, comme /themes/images/icons par exemple. Quoi qui se passe-t-il ? 404 ?
le 21 February 2012 à 10:47 h
@Topaze: NginX a sa propre syntaxe pour les règles de ré-écriture; il est possible de “traduire” pratiquement toutes les règles Apache en règles NginX, même si ces dernières sont un peu moins flexibles et sophistiquées (efficacité du serveur oblige). Une règle Apache simple du type de celle que tu évoques est très facile à traduire côté NginX.
le 14 March 2012 à 19:01 h
Bonjour,
Tres bon tuto, bien expliqué mais j’ai le même problème que Maxime. Si quelqu’un a une piste ce serai cool.
le 14 March 2012 à 21:19 h
Pour ma part, j’ai résolu mes soucis.
J’ai utilisé un fichier de config tel que celui-ci :
server {
listen 80;
server_name domain.fr http://www.domain.fr;
location / {
proxy_pass http://127.0.0.1:8080/;
access_log off;
}
location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|xml)$ {
root /var/www/domain;
error_log /var/log/nginx/domain.fr.errors.log;
expires 30d;
}
location ~ /\.ht {
deny all;
}
# redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/nginx-default;
}
}
Avec çà, impeccable, mes images, css et autres fichiers statiques sont bien renvoyés par Nginx (au vu des logs d’accès de Nginx)
le 15 March 2012 à 16:02 h
Salut Maxime
Je viens de tester ta conf et effectivement tout fonctionne a merveille.
Merci pour ta réactivité.
Cordialement,
Yohann
le 17 April 2012 à 9:03 h
J’ai un soucis…
Si je désactive le rewrite URL, ma page d’accueil s’affiche, avec les photos de la page d’accueil. Mais je suis obligé de spécifier http://monserveur:8080
Si je passe par http://www.monsite.fr
aucune image ne s’affiche ni sur la page d’accueil.
Si le rewrite URL est activé, aucune image ne s’affiche ni sur l’accueil, et de plus, dès que je clique sur une page du site, je me retrouve avec une page not found…
Si quelqu’un pourrait m’aider
Je suis sur Prestashop
le 17 April 2012 à 9:36 h
Finalement, j’ai réussi à tout faire fonctionner.
J’ai du faire
sudo service nginx restart
Bizarre…
Le seul dernier problème, c’est désormais mon fichier .htaccess
Car quand l’URL rewrite est activé, il en trouve aucune image, aucune page produit.
le 17 April 2012 à 9:39 h
@Excellent: NginX n’interprète pas les fichiers .htaccess. Donc s’il y a des règles de redirections en vigueur pour accéder aux fichiers statiques (images,…) il faut les “traduire” dans la configuration de NginX.
le 18 April 2012 à 2:42 h
Exact, j’avais oublié ce détail…
Merci pour les réponses en tout cas.
Actuellement, tout fonctionne.
J’ai mis les règles URL dans le fichier config de Nginx.
Les règles d’écriture sont bien faites, ma page d’accueil nikel, mais….
Lorsque je clique ailleurs (page d’un produit par exemple), ça marche pas…!
“La page n’est pas dirigée correctement”.
C’est le message que Firefox me renvoie.
Mon fichier config est celui ci :
server {
rewrite ^/([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$1$2.jpg last;
rewrite ^/([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$1$2$3.jpg last;
rewrite ^/([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$1$2$3$4.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.jpg last;
rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.jpg last;
rewrite ^/c/([0-9]+)(-[_a-zA-Z0-9-]*)/[_a-zA-Z0-9-]*.jpg$ /img/c/$1$2.jpg last;
rewrite ^/c/([a-zA-Z-]+)/[a-zA-Z0-9-]+.jpg$ /img/c/$1.jpg last;
rewrite ^/([0-9]+)(-[_a-zA-Z0-9-]*)/[_a-zA-Z0-9-]*.jpg$ /img/c/$1$2.jpg last;
rewrite ^/([0-9]+)-[a-zA-Z0-9-]*.html /product.php?id_product=$1 last;
rewrite ^/[a-zA-Z0-9-]*/([0-9]+)-[a-zA-Z0-9-]*.html /product.php?id_product=$1 last;
rewrite ^/([0-9]+)-[a-zA-Z0-9-]*(/[a-zA-Z0-9-]*)+ /category.php?id_category=$1&noredirect=1 last;
rewrite ^/([0-9]+)-[a-zA-Z0-9-]* /category.php?id_category=$1 last;
rewrite ^/([0-9]+)__([a-zA-Z0-9-]*) /supplier.php?id_supplier=$1 last;
rewrite ^/([0-9]+)_([a-zA-Z0-9-]*) /manufacturer.php?id_manufacturer=$1 last;
rewrite ^/content/([0-9]+)-([a-zA-Z0-9-]*) /cms.php?id_cms=$1 last;
rewrite ^/content/category/([0-9]+)-([a-zA-Z0-9-]*) /cms.php?id_cms_category=$1 last;
rewrite ^/erreur-404$ /404.php last;
rewrite ^/adresse$ /address.php last;
rewrite ^/adresses$ /addresses.php last;
rewrite ^/authentification$ /authentication.php last;
rewrite ^/meilleures-ventes$ /best-sales.php last;
rewrite ^/panier$ /cart.php last;
rewrite ^/jaimemavoiturefr-contactez-nous$ /contact-form.php last;
rewrite ^/bons-de-reduction$ /discount.php last;
rewrite ^/guest-tracking$ /guest-tracking.php last;
rewrite ^/historique-des-commandes$ /history.php last;
rewrite ^/identite$ /identity.php last;
rewrite ^/fabricants$ /manufacturer.php last;
rewrite ^/mon-compte$ /my-account.php last;
rewrite ^/nouveaux-produits-tuning-phares-et-feux-xenon$ /new-products.php last;
rewrite ^/commande$ /order.php last;
rewrite ^/details-de-la-commande$ /order-follow.php last;
rewrite ^/quick-order$ /order-opc.php last;
rewrite ^/avoirs$ /order-slip.php last;
rewrite ^/mot-de-passe-oublie$ /password.php last;
rewrite ^/les-promotions-de-jaimemavoiturefr$ /prices-drop.php last;
rewrite ^/recherche$ /search.php last;
rewrite ^/plan-du-site-de-jaimemavoiturefr$ /sitemap.php last;
rewrite ^/magasins$ /stores.php last;
rewrite ^/fournisseurs$ /supplier.php last;
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
root /var/www/www2;
expires 365d;
access_log off;
}
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
}
Ai-je raté quelque chose?
J’ai vraiment envie de ce Nginx !
Ca fait deux jours que je suis dessus, je me laisse encore deux jours maxi…
Sinon tant pis !
le 18 April 2012 à 3:56 h
Le message d’erreur complet :
”
La page n’est pas redirigée correctement
Firefox a détecté que le serveur redirige la demande pour cette adresse d’une manière qui n’aboutira pas.
La cause de ce problème peut être la désactivation ou le refus
des cookies.”
le 20 April 2012 à 18:24 h
@Excellent j’ai le même problème et je cherche aussi depuis 2 jours.. tu as trouvé la solution?
le 21 April 2012 à 10:01 h
@Excellent et @Y.Dubois on m’a donné la solution pour faire fonctionner les redirections de wordpress (ou autre) sur le forum ovh: changer tous les AllowOverride None par AllowOverride All dans le fichier /etc/apache2/sites-enabled/000-default
le 22 April 2012 à 16:59 h
@Jacques
Merci pour la réponse et désolé pour le retard.
J’avais pensé à ça aussi, et j’avais fait cette modif, mais rien y fait, j’ai toujours “La page n’est pas redirigée correctement”
As-tu gardé la config de Yann (que je remercie encore pour ses tutos) sans modification?
le 22 April 2012 à 17:06 h
Désolé pour le spam
J’ai oublié de précisé ceci :
Lorsque je ne mets aucune règle d’écriture dans le fichier config de nginx (default), tout fonctionne sauf les images qui ne s’affichent pas…
Lorsque je mets les règles d’écriture, toutes les images s’affichent, mais seule la page index fonctionne, le reste donne ““La page n’est pas redirigée correctement””
Je suis pas loin je pense mais Prestashop Forum ne se foule pas non plus.
Dernier jour passé dessus puis je zappe, c’est pas grave
le 22 April 2012 à 17:16 h
@Excellent ma config finale (nginx et apache) est postée ici http://forum.ovh.com/showthread.php?t=79056
le 27 April 2012 à 2:27 h
Salut tout le monde,
bon je suis du genre à ne jamais lâcher, et donc après une semaine de recherche, j’ai réussi à faire fonctionner de la manière suivante :
Il a fallu que je mette les règles d’écriture pour les fichiers statiques dans la conf de Nginx, et laissez les règles d’écriture pour le reste sur le .htaccess
A quoi voit-on que tout est bien activé?
Car je ne vois de “grosse” amélioration.
Dans le header, je vois bien qu’il passe par Nginx (“Server: nginx/0.7.67″)
le 27 April 2012 à 11:44 h
@Excellent
Les gains de performance de cette configuration se voient surtout au niveau de la mémoire consommée sur le serveur, et du nombre de threads simultanés. Inutile de dire qu’on ne verra aucun changement si on n’a pas un nombre suffisamment conséquent de requêtes simultanées.
En résumé, on peut accueillir plus de connexions et donc plus de visiteurs, à capacité mémoire et puissance égale du serveur. Quand on monte sur des très grosses charges la différence devient énorme, surtout au niveau de la consommation de mémoire. Si on a beaucoup d’images, la configuration “hybride” permet d’éviter la surconsommation de mémoire d’Apache en cas de pic de trafic.
Sinon, on ne voit pas de différence, c’est bien le but
le 27 April 2012 à 16:05 h
Yes exactement, j’étais pas très réveillé hier soir.
Vu que je suis tout seul à tester le site (site fermé au public pour le moment), je ne pourrai voir de différence.
Penses-tu qu’il est également préférable de faire passer les fichiers de type html par Nginx? Ou juste les fichiers images/son ?
Merci en tout cas pour ta disponibilité, tes tutos et ton blog.
le 27 April 2012 à 16:10 h
Dans cette configuration, tout ce qui n’utilise pas PHP (ce qu’on appelle couramment les fichiers “statiques”) doit passer directement par NginX. Le but est de solliciter Apache le moins possible. Donc oui, les fichier html fixes doivent passer par NginX.
le 27 April 2012 à 22:15 h
Excellent article, nous utilisons à présent Nginx sur tous nos hébergements Prestashop.
Le but étant de réduire le besoin de ressources pour offrir de meilleures performances avec une plus petite machine.
La configuration est assez longue (avec le HTTPS) mais vraiment configurer Nginx est un vrai plaisir ! Beaucoup plus souple qu’Apache selon moi.
Niveau perf, nos tests ont donné Nginx et le fastCGI vainqueur, et surtout plus simple à administrer.
Contactez nous si vous voulez des détails de comment héberger sa boutique Prestashop sur Nginx !
le 28 April 2012 à 6:35 h
@Prestadget
peux tu me communiquer stp les règles d’écriture pour les fichiers de type html ?
J’ai essayé ceux là mais en vain :
#rewrite ^/([0-9]+)-[a-zA-Z0-9-]*.html /product.php?id_product=$1 last;
#rewrite ^/[a-zA-Z0-9-]*/([0-9]+)-[a-zA-Z0-9-]*.html /product.php?id_product=$1 last;
rewrite ^/([a-zA-Z0-9-]*)/([0-9]+)\-([a-zA-Z0-9-]*)\.html(.*)$ /product.php?id_product=$2$4 last;
rewrite ^/([0-9]+)\-([a-zA-Z0-9-]*)\.html(.*)$ /product.php?id_product=$1$3 last;
#rewrite “^/lang-([a-z]{2})/([a-zA-Z0-9-]*)/([0-9]+)-([a-zA-Z0-9-]*).html /product.php?id_product=$3&isolang=$1″ last;
#rewrite “^/lang-([a-z]{2})/([0-9]+)-([a-zA-Z0-9-]*).html /product.php?id_product=$2&isolang=$1″ last;
rewrite “^/lang-([a-z]{2})/([a-zA-Z0-9-]*)/([0-9]+)\-([a-zA-Z0-9-]*)\.html(.*)$ /product.php?id_product=$3&isolang;=$1$5″ last;
rewrite “^/lang-([a-z]{2})/([0-9]+)\-([a-zA-Z0-9-]*)\.html(.*)$ /product.php?id_product=$2&isolang;=$1$4″ last;
le 29 April 2012 à 15:02 h
Bonjour,
NgenX semble opérationnel sur mon serveur mais lorsque je consulte le header d’une page php, c’est ngenx qui est indiqué. Ce qui laisserait penser qu’il ne donne pas la main à Apache.
Pourtant mes rewriting Apache (.htaccess) fonctionnent… Y’a t’il une explication au fait que le header comporte ngenx même pour des pages rewritées par Apache ?
Nicolas.
le 29 April 2012 à 21:08 h
Question subsidiaire, comment peut-on forcer l’expiration d’un fichier si l’on y apporte une modification ?
Nicolas.
le 30 April 2012 à 10:12 h
@Nicolas : chaque type de cache a ses propres modalités de gestion de l’expiration; de quel niveau cache parles-tu ? (cache opcode type eAccelerator, cache applicatif, cache du navigateur ?)
le 30 April 2012 à 10:44 h
Bonjour Yann,
Je parlais du cache lié à l’expiration de 365 jours que tu indiques dans le virtualhost de NginX.
Certains utilisent proxy_cache_path dans la config de NginX pour préciser l’emplacement du cache et diverses autres paramètres.
Pour le fait que le header d’une page PHP me retourne NginX au lieu de Apache, tu as une idée de la raison ?
Merci, Nicolas.
le 30 April 2012 à 21:26 h
Ok, j’ai confondu le cache navigateur dont le “expires 365d” gère la durée de vie et le cache serveur de NginX qui n’est pas activé dans la configuration de cette page.
Est-ce intéressant d’activer le cache serveur de NginX ?
Nicolas.
le 28 July 2012 à 1:43 h
J’ai une petite question, je ne sais pas si tu sera en mesure de me répondre. J’ai suivi la plupart de tes tuto mais aujourd’hui j’aurai besoin d’une info.
J’ai une boutique sur prestashop, et je voudrais donc mettre nginx en reverse proxy mais comment cela va se passer sachant que j’ai un certificat SSL sur mon prestashop.
Est-ce possible de mettre en place nginx en reverse proxy malgré que j’ai une partie du site en SSL ? Il y a t-il quelque chose de spécial a faire ? puisque les images devraient donc être chargé avec ngix et le protocole SSL et en meme temps apache avec SSL pour le php.
Cela va t-il créer un conflit au niveau de mon certificat ssl ?
Merci d’avance
le 14 August 2012 à 0:38 h
Pour servir plusieurs hôtes virtuels, il est impératif de placer :
listen 80 default; ou
listen 80 default_server; dans :
/etc/nginx/sites-available/default.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564726
Puis, créer autant d’hôtes virtuels qu’il est nécessaire sur le modèle donné par Yann Dubois pour le site par défaut, de cette façon :
# cp /etc/nginx/sites-available/default /etc/nginx/sites-available/machin
# vi (éditer les noms du server_name et du fichier root comme pour Apache)
# ln -s /etc/nginx/sites-available/machin /etc/nginx/sites-enabled/machin
Sinon, un seul domaine est pris en compte pour la distribution des fichiers statiques, les autres en étant dépourvus.
le 14 August 2012 à 8:06 h
@Philippe
Merci pour cette précision !
le 7 April 2013 à 23:26 h
Bonjour, 2 ans après, je reviens faire un tour sur ce tuto toujours aussi pratique pour mettre en place un serveur et viens y contribuer concernant la config de Nginx. J’ai vu que d’autres utilisateurs (commentaire n°13) rencontrait ce problème, à savoir : problème d’affichage des images sur PhpMyadmin, munin et phpsysinfo.
Voici ma solution qui pourrait être intégrée au tuto (si cela vous intéresse bien sûr) ):
Dans le fichier /etc/nginx/sites-available/default, avant la ligne :
location ~* \.(jpg|jpeg|gif|css|png|js|ico|swf|mp3)$ {
il faut insérer la directive suivante :
location ~* ^/(awstats|phpmyadmin|munin|phpsysinfo) {
proxy_pass http://127.0.0.1:8080;
include /etc/nginx/proxy.conf;
}
PUIS, si ce n’est pas déjà le cas, créer un fichier ” /etc/nginx/proxy.conf ”
dont le contenu est plus ou moins le suivant :
############
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;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 32k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
##################
Et voilà, pour ces répertoire, Nginx ne prend pas en charge les images et fichiers statiques.
A noter que j’ai trouvé cette solution sur ce lien : http://kastang.com/blog/2010/08/howto-awstats-and-phpmyadmin-to-display-properly-using-nginx-and-apache/
Bien cordialement,
Renaud
le 8 April 2013 à 11:06 h
@Renaud, merci d’avoir partagé !
@Tous : j’utilise maintenant exclusivement NginX (sans Apache) pour tous mes hébergements WordPress et c’est la solution que je recommande à tous mes clients étant donnée sa très grande stabilité y compris sous très forte charge genre 200KVU/jour sous WordPress. Pour le cache d’opcode, j’utilise désormais APC. non pas que j’ai vu de différence de performance notable avec eAccelerator, mais son installation et sa mise à jour sont plus simples sur Debian ou Ubuntu, et il est également très stable avec php-fpm. J’espère trouver le temps bientôt d’écrire un petit article sur la configuration full NginX + APC et son optimisation (car il y a quelques réglages à faire pour que cela fonctionne au mieux avec WordPress).
le 8 April 2013 à 15:27 h
Bonjour,
.
J’ai hâte de consulter ton futur tuto optimisé WordPress. J’héberge un site WordPress sur un dédié KS R-4G et il tombe à la moindre pointe de fréquentation. Il faut dire qu’il est blindé de plugins dont WPML
Nicolas.
le 8 April 2013 à 15:44 h
Oui, 4 Go de RAM pour un WordPress avec plein de plugins, c’est devenu juste. Ceci dit, jusqu’à récemment j’avais un serveur KS avec seulement 2Go de RAM qui arrivait à peu près à faire tourner une douzaine de WordPress à fréquentations faibles à moyenne (moins de 2000 VU/jour chacun). Passer en full-NginX améliorera la consommation mémoire par rapport à Apache. WPML n’est pas le pire des plugins pour la consommation mémoire (certains plugins de cache font pire), et de toute façon c’est la seule solution un peu pro pour le multilinguisme, même si leur structure de base de données est un peu une usine à gaz.
le 8 April 2013 à 16:43 h
En fait ce n’est pas la ram qui semble prendre cher lors de pics de fréquentation (fréquentation < 2000 VU en temps normal).
Le load par contre s'emballe jusqu'à bloquer le serveur (160 de load, CPU à 100%). J'ai installé Quick Cache + DB Cache Reloaded Fix + Lazy Load, ce qui améliore la navigation sur le site mais n'empêche pas la montée en charge en cas de pic de fréquentation. Je pense que le site a un problème d'optimisation (thème ou plugin), mais comme je ne l'ai pas réalisé, je ne peux pas creuser plus.
le 8 April 2013 à 16:48 h
@Yann : Pour des raisons personnelles (multisite dont je ne gérerais pas forcément le contenu mais sur lesquels, je pourrais donner mon avis), je ne souhaite pas passer sur du full Nginx.
Par contre, j’aurais bien tenter le trio Nginx + Apache + Varnish, avec à peu près cette config : http://www.fabrizio-branca.de/nginx-varnish-apache-magento-typo3.html
Penses-tu que c’est judicieux ?
Merci
le 8 April 2013 à 16:59 h
@Renaud: à mon avis dans la plupart des cas Varnish ne sera pas utile en plus de NginX et d’un bon plugin de cache statique pour WordPress (type W3 Total Cache). On peut en effet utiliser NginX pour servir le cache statique directement. Sur un gros site WordPress que je supervise, l’hébergeur a fait des essais en ajoutant Varnish sur un frontal, et on ne voit pas la différence, ce qui ne m’étonne pas car il fait double emploi avec le cache W3TC géré directement par NginX correctement configuré. Le seul cas où je vois Varnish jouer un rôle, c’est si on commence à vouloir mettre en cache des morceaux de page avec Edge Side Includes, mais ça n’est pas géré en natif par WordPress. Bien que ce soit tout à fait faisable, certains l’on fait… Dans ce cas pourquoi pas, mais c’est peut-être NginX qui devient inutile s’il y a déjà Apache.
le 8 April 2013 à 17:08 h
@Nicolas: Avec WordPress, ça ne bloque en général qu’à deux endroits : soit c’est la base de données, soit c’est la RAM. Et si c’est la RAM sur un petit serveur OVH ça fera exploser la charge car le serveur va se mettre à swapper sur disque. Donc la première chose à vérifier reste la RAM : dès qu’il utilise le swap, c’est mort. Pour réduire la RAM utilisée il faut un bon cache d’opcode bien configuré (APC ou eAccelerator) et passer à NginX. Si c’est la base il faut installer un plugin de cache genre W3 Total Cache, passer les tables les plus utilisées en InnoDB, et virer les plugins malfoutus qui sont légion. A priori, à 2000VU sur un dédié sous WordPress, à moins que les 2000 visiteurs se pointent tous en même temps pour regarder des pages différentes, il n’y a pas de raison que ça ne passe pas. Sans plugin pourris, j’ai fait des 3000 ou 4000VU par heure sur un WordPress avec un kimsufi de 2Go de RAM. Sur un serveur un peu plus musclé en mémoire, WP ne posera pas de problème avant 30000 VU/jour.
le 8 April 2013 à 17:16 h
@Yann Merci pour ton retour… En effet, j’ai déjà paramétré le cache statique Nginx. Eventuellement, si j’ai un peu de temps à perdre, je testerais Varnish entre Nginx et Apache, ce qui dont être utile dans un cas il n’y a pas de cache statique WP ou autre. (des pages .php classique en somme).
Je ferais un retour d’expérience si je vois une amélioration nette mais il me faudra quelques centaines de VU par minutes en plus
le 16 May 2013 à 11:29 h
Après avoir suivi ce tuto pour mettre NginX en proxy, ce qui se révèle très satisfaisant, je suis passé à NginX et php-fpm, mais avec CloudFlare passé en proxy. Résultat : une augmentation immédiate du nombre de visites.
Pour l’instant, le temps de latence est un peu plus long que précédemment, mais je pense pouvoir améliorer un peu les réglages, et c’est compensé par un accès plus rapide au serveur.