Optimiser son serveur Web avec Nginx

Si vous êtes l’heureux possesseur d’un site hébergé sur un serveur dédié, la popularité est une bonne chose mais peut vite s’accompagner d’autres inconvénients comme la saturation des ressources de votre serveur.

La solution la plus simple est souvent de passer à une offre supérieure (et donc plus chère), mais cela peut être sans fin ou presque, et les migrations ne sont pas forcément une partie de plaisir. Modifier l’architecture est parfois une meilleure solution et permet de mieux profiter de son hébergement actuel sans trop d’efforts et sans surcoût. Si vous travaillez bien, vous pourrez en plus anticiper le passage à une architecture à plusieurs serveurs.

Pourquoi mon serveur plante ?

Le problème principal affectant les serveurs Web comme Apache est la quantité de RAM disponible sur le système. Un serveur ne devrait jamais saturer sa RAM et utiliser le SWAP, c’est-à-dire la mémoire virtuelle sur le disque dur.

Si le SWAP est utilisé, le temps de réponse du serveur augmente, et les visiteurs rafraichissent alors plusieurs fois la page accentuant encore la charge sur le serveur. Le SWAP se remplit alors dangereusement et les autres processus du système deviennent à leur tour inaccessibles ou très lents (MySQL, SSH, etc.).

Il faut alors bien souvent redémarrer au moins le processus Apache.

La valeur à ajuster pour éviter certains problèmes est « MaxClients » :  elle correspond au nombre maximum de visiteurs qui pourront être servis simultanément. Positionnez cette valeur trop bas et les requêtes seront placées en file d’attente alors qu’il reste des ressources sur le serveur. Positionnez cette valeur trop haut et la consommation de ressources sera trop importante, jusqu’au swap… vous connaissez la suite.

Pour bien configurer cette valeur, il n’y a pas de miracle : il faut tester plusieurs configurations et voir comment le système réagit à la charge. La documentation Apache préconise de faire le calcul suivant : MaxClients = Mémoire totale disponible pour Apache / Mémoire moyenne d’un processus Apache.

Par exemple, sur un système avec 2 Go de mémoire, si vous souhaitez laisser 1800Mo à Apache, et si un processus Apache prend 10Mo en moyenne, MaxClients sera égal à 1800/10 = 180. En pratique, il sera souvent possible de mettre un peu plus, la mémoire affichée comme étant allouée à un processus n’étant pas forcément totalement utilisée.

A vous de voir pour la mémoire totale disponible pour Apache, elle doit correspondre à la mémoire totale de votre système moins celle que vous voulez accorder aux autres processus.

La mémoire moyenne d’un processus Apache peut être obtenu à l’aide de la commande « top » ou d’une commande de ce style :

ps -ylC apache2 --sort:rss

(La mémoire utilisée par les processus étant indiquée en ko dans la colonne RSS).

Séparer contenu dynamique et contenu statique

Lorsque l’on utilise Apache avec du contenu dynamique (avec mod-php5 par exemple), la mémoire utilisée par un processus peut vite devenir importante (6 -30Mo), et elle ne sera pas libérée immédiatement par ce processus. Que ces processus distribuent également le contenu statique (images, css, html, fichiers textes, documents, archives,etc. )  n’est pas forcément le plus adapté.

Traiter ces deux types de contenus par deux processus différents est souvent préférable au niveau des performances. Pour cela, il y a plusieurs solutions envisageables : utiliser mod_proxy et transmettre certaines requêtes à un autres processus Apache, ou utiliser un autre serveur Web reconnu pour ses performances notamment pour le traitement des fichiers statiques.

Pour ce dernier choix, deux serveurs Web alternatifs font parler d’eux : Lighttpd (lighty pour les intimes) et nginx (Engine X).

nginx

Nginx est un serveur Web/reverse proxy léger développé par Igor Sysoev. Il a été utilisé depuis plusieurs années sur des sites russes à gros traffic tel que Rambler, avant d’être plus largement répandu aujourd’hui : WordPress.com, hulu, Gravatar, Kongregate, userscripts.org et même YouPorn (gage de qualité, n’est-t-il pas ?).

Installation de nginx

Pour l’installation, une fois les sources téléchargées, il suffit de lancer le classique :

./configure
make
sudo make install

Ou si vous utilisez des dépôts récents sous Debian :

apt-get install nginx

En fonction de l’installation choisie, les répertoires pourront varier dans ce qui suit.

Configuration de base

La configuration serveur de nginx est relativement sommaire, ce qui a au moins le mérite de nous éviter le casse-tête du tuning comme avec Apache ou MySQL.

/etc/nginx/nginx.conf
 
user www-data;
worker_processes  1;
 
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;
 
    sendfile        on;
    #tcp_nopush     on;
 
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
 
    gzip  on;
 
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

La configuration initiale est performante et devrait convenir à une majorité de sites Web. Il est conseillé d’éviter de modifier le nombre de « worker_processes » sauf si vous savez ce que vous faites (serveur multi-core par exemple). L’architecture du processus est largement différente de celle d’Apache et plusieurs processus n’amélioreront pas forcément vos performances.

Nginx est un serveur asynchrone par opposition aux serveurs synchrones où chaque requête est traitée par un processus dédié. Au lieu d’exploiter une architecture parallèle et le multiplexage temporel des tâches par le système d’exploitation, Nginx utilise les changements d’états pour gérer plusieurs connexions en même temps ; le traitement de chaque requête est découpé en de nombreuses mini-tâches et permet ainsi de réaliser un multiplexage efficace entre les connexions. Afin de tirer parti des ordinateurs multi-processeurs, plusieurs processus peuvent être démarrés. Ce choix d’architecture se traduit par des performances très élevées mais également par une charge et une consommation de mémoire particulièrement faibles comparativement aux serveurs HTTP classiques tels qu’Apache. (Source)

Pour des configurations plus avancées, vous pouvez consulter cet exemple, ou celui-ci.

Utiliser nginx pour votre contenu statique

Dans cette configuration, simple à mettre en œuvre, nginx sera placé en amont d’un serveur Apache et s’occupera de tous les fichiers statiques (images, CSS, textes, etc.) et toutes les autres requêtes seront envoyées normalement au serveur Apache.
Cette configuration sera pertinente surtout si votre serveur ne passe pas 90% de son temps à construire des pages dynamiquement (PHP). Avec WordPress, cette configuration sera intéressante si vous utilisez déjà un système de cache. Dans le cas contraire, je vous invite à consulter cet article au préalable : WordPress : optimiser son blog avec un système de cache, ou d’aller jusqu’à la fin de cet article pour utiliser également nginx en tant que cache.

/etc/nginx/sites-available/default
 
server {
  listen      80;
  server_name www.papygeek.com;
 
  access_log  /var/log/nginx/papygeek.com-access.log;
  error_log   /var/log/nginx/papygeek.com-error.log;
 
  # Les requêtes sont transmises au processus Apache écoutant en local sur le port 8080
  location / {
    proxy_pass         http://127.0.0.1:8080/;
    include  /etc/nginx/proxy.conf;
  }
 
  # On distribue les fichiers statiques directement
  location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
    root  /var/www/papygeek.com/;
    access_log  /var/log/nginx/static-papygeek.com-access.log;
    error_log   /var/log/nginx/static-papygeek.com-error.log;
    expires           30d;
  }
}

/etc/nginx/proxy.conf
 
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          4k;
proxy_buffers               4 32k;
proxy_busy_buffers_size     64k;
proxy_temp_file_write_size 64k;

Ceci fonctionne dans le cas où vous n’avez qu’un seul site hébergé sur votre serveur. Dans le cas d’une configuration avec des virtual hosts, il faudra soit configurer chaque domaine, soit ajouter une règle générique qui transmettra les requêtes des autres domaines au serveur Apache :

/etc/nginx/sites-available/default
 
...
 
server {
  listen 80 default;
  server_name _;
 
  # Ici on désactive les access_log pour ne pas faire doublon avec Apache
  access_log        off;
  #access_log  /var/log/nginx/default.access.log;
 
  server_name_in_redirect on;
 
  location / {
    proxy_pass         http://127.0.0.1:8080/;
    include /etc/nginx/proxy.conf;
  }
}

Il faudra ensuite modifier la configuration de votre serveur Apache pour que celui-ci écoute sur le port 8080. Il ne sera accessible que localement, puisque toutes les requêtes passeront maintenant par nginx.

Pensez à faire une sauvegarde de vos fichiers avant de vous lancer dans les modifications.

Il faut modifier dans tous vos fichiers de configuration Apache les références au port 80, qui devient 8080 ici, ainsi que les références à l’IP de votre serveur, qui devient 127.0.0.1.

/etc/apache2/apache2.conf
 
NameVirtualHost 127.0.0.1:8080

/etc/apache2/ports.conf
 
Listen 127.0.0.1:8080

Et dans vos virtual hosts :

/etc/apache2/sites-available/papygeek.com
 
<VirtualHost 127.0.0.1:8080>
  ServerAdmin papygeek@gmail.com
  ServerName papygeek.com
  DocumentRoot /var/www/papygeek.com
  ...
</VirtualHost>

Il ne vous reste plus qu’à redémarrer tout ça et à croiser les doigts :

/etc/init.d/apache2 restart
/etc/init.d/nginx start

Pour en savoir plus sur nginx, vous trouverez de nombreuses informations sur ce Wiki, notamment pour l’installation.

Utiliser nginx en tant que cache

Même si nginx n’est pas prévu pour être utilisé en tant que cache (contrairement à Squid par exemple), il est possible d’utiliser la fonction proxy_store pour créer un miroir du site en backend.

Voici un exemple de configuration pour débuter, dans le cas de l’utilisation de WordPress avec réécriture d’URL :

/etc/nginx/sites-available/default
 
server {
  listen      80;
  server_name www.papygeek.com;
 
  access_log  /var/log/nginx/papygeek.com-access.log;
  error_log   /var/log/nginx/papygeek.com-error.log;
 
  include  /etc/nginx/proxy.conf;
 
  location / {
    # Notre répertoire de cache, à créer.
    root /var/www/papygeek.com/fetch;
 
    # On n'utilise pas le cache pour les requêtes des utilisateurs connectés
    if ($http_cookie ~ "comment_author_|wordpress|wp-postpass_" ) {
      access_log off;
      proxy_pass http://127.0.0.1:8080;
      break;
    }
    # On n'utilise pas le cache pour les requêtes avec des query strings
    if ($query_string) {
      access_log off;
      proxy_pass http://127.0.0.1:8080;
      break;
    }
    if (-f $request_filename/_cache.html) {
      rewrite (.*) $1/_cache.html;
    }
    error_page 403 404 = /fetch$uri;
  }
 
  # Lorsque le cache ne contient pas la page (404), on interroge Apache et on stocke le résultat.
  location  ^~ /fetch/ {
    internal;
    proxy_pass http://127.0.0.1:8080;
    proxy_store /var/www/papygeek.com${uri}_cache.html;
    proxy_store_access user:rw group:rw all:r;
  }
 
  # Les requêtes vers des fichiers php et l'administration du blog ne doivent pas utiliser le cache
  location ~ (\.php$|^/wp-admin) {
    root  /var/www/papygeek.com/;
    proxy_pass http://127.0.0.1:8080;
  }
 
  # On distribue les fichiers statiques directement
  location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
    root  /var/www/papygeek.com/;
    access_log  /var/log/nginx/static-papygeek.com-access.log;
    error_log   /var/log/nginx/static-papygeek.com-error.log;
    expires           30d;
  }
}

Les commentaires dans le code devrait être relativement explicites. On détourne ici la fonction « error_page » pour lancer une requête vers le serveur Apache lorsqu’une page n’est pas trouvée dans le cache. Le résultat est alors stocké pour la prochaine requête. La configuration est assez particulière mais nécessaire lorsque les pages du site ne se terminent pas par .html (nginx ne sachant pas stocker les pages par défaut dans ce cas). (Source)

Ce système remplace habilement WP Super Cache qui fonctionne sur un principe similaire. A une petite différence près : ici les fichiers ne sont jamais purgés, il faudra donc effectuer cette purge régulièrement pour s’assurer de la fraicheur des pages.
Ceci peut être effectué facilement en ajoutant une tâche ou un script en crontab.

On peut également penser extraire et adapter la partie du code de WP Super Cache s’occupant de la purge du cache pour en faire un plugin WordPress.

Une autre approche qui ne fonctionne que si WP Super Cache est installé, est de ne pas créer de cache du côté d’nginx mais de rooter directement les utilisateurs vers les fichiers de cache de WP Super Cache (sans passer par Apache). De nombreuses ressources discutent de cette solution sur le Web, je vous laisse faire vos retours sur cette technique. Exemples : How To Speed Up WordPress With Nginx And WP Super Cache, nginx rewrite rules for WordPress + WP Super Cache, Nginx SuperCache WP Super Cache Plugin Rewrites WordPress Mu.

De manière complètement différente, il est également possible de tester l’utilisation d’nginx seul, avec PHP en FastCGI. Il faudra alors également trouver les bonnes règles de réécriture pour les URL du site. Dans ce cas, l’utilisation de lighttpd est peut-être préférable les ressources sur le Web étant plus abondantes pour l’instant.

Corriger le problème de l’adresse IP des clients

Un petit problème peut se produire lorsque l’on utilise un reverse-proxy comme dans notre configuration : l’IP des clients affichée par certains scripts PHP sera l’IP du proxy (127.0.0.1 si les deux processus sont sur la même machine). C’est le cas par exemple pour l’IP des commentaires dans WordPress.
Pour corriger ce problème, une solution relativement simple existe : l’installation du module rpaf.

Sous debian, l’installation de mod_rpaf s’effectue le plus simplement du monde :

apt-get install libapache2-mod-rpaf

Le module devrait alors être activé, dans le cas contraire :

a2enmod rpaf
/etc/init.d/apache2 restart

(Source).

Et après ?

Si la charge de votre serveur augmente encore, vous aurez alors plusieurs possibilités en fonction de la nature de votre site et du goulot d’étranglement (MySQL ou Apache par exemple) :

• Déplacer Apache sur un autre serveur (si c’est le processus Apache qui sature),
• Déplacer MySQL sur un autre serveur (si c’est le processus Apache qui sature),
• Ajouter un autre serveur Apache grâce à la fonction de load-balancer d’nginx,
• Ajouter un autre serveur MySQL, plusieurs serveurs Apache, plusieurs nginx, et trouver un site qui a besoin de toutes ces ressources

Exemple de configuration d’nginx en tant que load balancer :

http {
    upstream myproject {
        server 127.0.0.1:8000 weight=3;
        server 127.0.0.1:8001;
        server 127.0.0.1:8002;    
        server 127.0.0.1:8003;
    }
 
    server {
        listen 80;
        server_name www.domain.com;
        location / {
            proxy_pass http://myproject;
        }
    }
}

Les configurations précédentes sont très simples à adapter dans cette optique.

Voilà, c’est tout pour cette fois, je pense que vous avez de quoi bosser. Si vous cherchez d’autres tutoriels sur nginx, voici un bon début. Merci à Stagueve de m’avoir orienté sur ce produit et enrichi ma culture