Apache avec Nginx

Vous pouvez optimiser le fonctionnement du serveur Web qui héberge les sites Web des clients (Apache) en installant Nginx, un autre serveur Web extrêmement performant généralement utilisé en tant que serveur proxy inversé. Ce serveur Web a été spécialement conçu pour prendre en charge de grands volumes de contenu statique (de type images, vidéos, css, xml, etc.). Par opposition à Apache, Nginx est beaucoup plus efficace pour traiter un gros volume de connexions simultanées. Autre atout de ce serveur Web par rapport à Apache : Nginx utilise beaucoup moins de mémoire par connexion client.

Pour profiter de tous les avantages de Nginx, Plesk le configure en tant que serveur proxy inversé situé entre Internet et Apache (cf. le schéma ci-dessous). Autrement dit, Nginx devient un serveur Web frontal qui traite toutes les requêtes entrantes des visiteurs des sites. Les requêtes sont envoyées vers Apache, qui, en retour, différencie les requêtes pour le contenu statique et dynamique. Si une requête est destinée à un fichier statique (comme jpg, css, html, etc. ), Apache passe la demande à tous les gestionnaires enregistrés (s'applique à la configuration au niveau du répertoire .htaccess, réécrit une URL, etc) et renvoie à Nginx une réponse qui ne contient qu'un emplacement du fichier requis sur le système de fichiers. Nginx localise le fichier et l'envoie au client. Si la requête est destinée à un fichier dynamique (comme un script PHP), Apache exécute le fichier et envoie la réponse à Nginx, qui l'envoie au client.

Une telle combinaison de Nginx et Apache apporte les avantages suivants :

  • Augmentation du nombre maximal de connexions simultanées à un site Web.
  • Diminution de l'utilisation des ressources mémoire et CPU du serveur.
    L'effet maximal est atteint pour les sites Web avec un large volume de contenu statique (type galeries de photos, sites de streaming vidéo, etc.).
  • Amélioration de l'efficacité en matière de prestations fournies aux visiteurs avec une connexion Internet lente (GPRS, EDGE, 3G, etc.).
    Par exemple, un client avec une connexion à 10 Ko/s a besoin d'un script PHP qui génère une réponse à 100 Ko. Si le serveur ne dispose pas de Nginx, la réponse est fournie par Apache. Pendant les 10 secondes requises pour envoyer la réponse, Apache et PHP continuent d'utiliser toutes les ressources du système pour cette connexion ouverte. Si Nginx est installé, Apache transfère la réponse à Nginx (la connexion Nginx vers Apache est très rapide, les deux étant sur le même serveur) et libère ainsi des ressources système. Comme le volume de mémoire de Nginx est plus faible, la charge générale sur le système diminue. S'il y a beaucoup de connexions lentes de ce type, l'utilisation de Nginx optimisera largement la performance du site Web.

Vous trouverez plus de détails techniques sur la manière dont Plesk traite les requêtes HTTP avec Nginx dans cette section. Pour en savoir plus sur l'activation de l'assistance Nginx dans Plesk, reportez-vous à la section Installer Nginx. Si vous ne voulez pas utiliser Nginx, faites d'Apache votre serveur Web frontal en procédant comme décrit dans la section Désactiver Nginx. Si vous souhaitez que Nginx traite toutes les requêtes HTTP pour le contenu Web, consultez la section Ajuster les paramètres du serveur Web Apache.

Traitement des requêtes HTTP par Plesk avec Nginx

Pour intégrer sans heurt Nginx à Apache, Plesk utilise deux modules Apache supplémentaires :

  • mod_aclr2.
    Ce module configure un gestionnaire qui s'exécute après les gestionnaires de tous les autres modules Apache (mod_rewrite, modules associés .htaccess, mod_php, etc). Par conséquent, si la requête est destinée au contenu dynamique, mod_aclr2 ne l'obtiendra jamais car la requête sera servie par des gestionnaires de niveau supérieur de certains modules Apache (mod_php, mod_perl, mod_cgi, etc.). Les seules exceptions sont les requêtes SSI : une fois qu'elles atteignent mod_aclr2, il les redirige vers les gestionnaires corrects. Si la requête est destinée à un fichier statique, mod_aclr2 recherche l'emplacement exact du fichier sur le système de fichiers et envoie l'emplacement à Nginx.
  • mod_rpaf.
    Du point de vue d'Apache, tous ses clients ont la même adresse IP, l'adresse du serveur Nginx (cf. le schéma ci-dessous). Cela entraîne des problèmes avec les sites Web et les applications Web qui utilisent les adresses IP des clients à des fins d'authentification, de statistiques, etc. mod_rpaf résout le problème en remplaçant l'adresse IP du serveur Nginx dans toutes les requêtes par des adresses IP clientes. Pour être plus précis, le module utilise l'en-tête spéciale X-Forwarded-For (X-Redirigée-Pour) dans laquelle Nginx place l'adresse IP d'un client.

Regardons de plus près comment Plesk traite les requêtes pour le contenu statique et dynamique à l'aide de ces modules.

La séquence de traitement d'une requête HTTP pour un fichier statique se présente comme suit (cf. le schéma) :

  1. Un client envoie une requête à un serveur Web.
  2. Nginx ajoute les en-têtes X-Accel-Internal (utilisée par mod_aclr2) et X-Forwarded-For (contient l'adresse IP du client) à la requête qu'il envoie à Apache.
  3. Apache reçoit la requête et initie le traitement par des gestionnaires enregistrés (applique la configuration .htaccess, réécrit l'URL, etc.). À cette étape, mod_rpaf remplace l'adresse IP du serveur Nginx dans la variable d'Apache REMOTE_ADDR par l'adresse du client à partir de l'en-tête X-Forwarded-For.
  4. Une fois la requête traitée par tous les gestionnaires enregistrés, elle atteint mod_aclr2. Le gestionnaire vérifie la présence de l'en-tête X-Accel-Internal. Si l'en-tête est présent, le module envoie à Nginx une réponse avec une longueur de contenu nulle et l'en-tête X-Accel-Redirect. L'en-tête contient l'emplacement exact du fichier tel qu'il est déterminé par mod_aclr2.
  5. Lorsque Nginx reçoit la réponse, il localise le fichier et le remet au client.

Le schéma ci-dessous illustre comment Plesk traite la requête d'un fichier GIF de 2 Ko.

static_seq

En cas de traitement des requêtes de contenu dynamique, les étapes 1 à 3 sont identiques. Ensuite, la requête passe dans le gestionnaire du module Apache approprié (mod_php, mod_perl, mod_cgi, etc.). La requête n'atteint jamais mod_aclr2 (sauf les requêtes SSI). Le gestionnaire génère une réponse et l'envoie à Nginx, qui, en retour, remet la réponse au client. Le schéma ci-dessous illustre comment Plesk traite une requête de fichier PHP.


Dans cette section :

Installer Nginx

Désactiver Nginx

 

Installer Nginx

Si vous procédez à une première installation de Plesk, Nginx sera activé par défaut. Si vous mettez à niveau à partir de versions antérieures, vous pouvez ajouter le composant Nginx à tout moment après la mise à niveau dans Outils & Paramètres > Mises à jour & Mises à niveau > Ajouter des composants. Une fois le composant ajouté, vous devez exécuter le service Serveur Proxy inversé (Nginx) dans Outils & Paramètres > Gestion des services.

Vous pouvez voir la version du serveur Nginx installé dans Outils & Paramètres > Composants du serveur.

nginx version

  

 

Désactiver Nginx

Pour revenir à la configuration avec un seul serveur Web Apache, stoppez le service Reverse Proxy Server (Nginx) dans Outils & Paramètres > Gestion des services.

nginx_stop

Pour rétablir Nginx dans le serveur Web frontal, lancez le service Reverse Proxy Server (Nginx).

Remarque : les opérations de démarrage et d'arrêt du service Reverse Proxy Server (Nginx) ne démarrent et n'arrêtent pas simplement Nginx, elles activent la configuration du serveur Web (combinaison de Nginx et d'Apache ou juste Apache en tant que serveur Web frontal). L'opération de redémarrage fonctionne de la même manière pour tous les autres services : le service Nginx est redémarré.

 

Leave your feedback on this topic here

If you have questions or need support, please visit the Plesk forum or contact your hosting provider.
The comments below are for feedback on the documentation only. No timely answers or help will be provided.