Derrière toute application web (site internet, messagerie…) se cachent un ou plusieurs serveur(s) web. Ils satisfont les requêtes des internautes, en servant à leurs navigateurs les fichiers permettant d’afficher la page demandée.

Ces fichiers peuvent être statiques, et donc stockés sur le serveur web (HTML, CSS) ; ou bien ils sont dynamiques et nécessitent une interprétation (comme PHP), auquel cas le serveur enverra une requête à un autre service, qui lui fournira un fichier qu’il pourra analyser et renvoyer.

Il existe plusieurs solutions de serveurs web : NGINX, Apache 2, Lighttpd, IIS (pour les environnements Microsoft)… Nous nous intéresserons en particulier dans cet article à NGINX et Apache, deux serveurs web fonctionnels sur les environnements Linux et utilisés par NBS System.

Choisir un serveur web

Lorsque l’on doit choisir une nouvelle technologie, c’est pour pallier un problème ou mettre en place un nouvel outil. La première étape est donc de définir précisément son besoin, auquel la technologie devra répondre, ainsi que les contraintes auxquelles elle devra s’adapter. C’est là qu’a lieu le premier tri dans les solutions : ne sont gardées que celles qui répondent au besoin premier, et qui peuvent s’adapter aux contraintes.

Cela fait, reste à choisir entre les technologies short-listées, afin de savoir laquelle est la plus adaptée au contexte de production de l’entreprise. Pour cela, on étudie chaque phase de la vie de la technologie pour trouver la solution la plus adéquate par rapport au budget de l’entreprise, à la taille et aux compétences techniques de ses équipes, et à sa philosophie. On distingue alors deux phases :

  • Build pictureLe « build » : cela correspond au déploiement et à la mise en production de la solution.
  • Le « run » : ce sont les méthodes de maintenance et les capacités d’évolution, de monitoring et de métrologie d’une solution.

L’étude de ces deux phases permet de quantifier la mise en place et le maintien de la solution dans le temps : ces deux visions sont nécessaires pour choisir la plus adaptée à son entreprise.

NBS System a choisi, de cette manière, deux solutions : NGINX et Apache. Elles ont la même fonction, mais répondent à des contraintes différentes, comme nous allons le voir.

Les différences entre ces solutions de serveur web sont relativement peu marquées, mais elles ont le mérite d’être exposées.

Industrialisation des outils

automatisationLes facilités d’industrialisation sont un critère important dans le choix d’une technologie, puisque cette caractéristique va jouer tout au long du cycle de vie du serveur, depuis sa création jusqu’à sa destruction, en passant par son exploitation. C’est d’autant plus important pour un hébergeur infogérant tel que NBS System, puisque les serveurs web sont notre cœur de métier : leurs fonctionnements doivent suivre les changements applicatifs de nos clients. L’automatisation des processus gagne du temps, et permet d’éviter les erreurs humaines.

Le choix de notre équipe est NGINX, plus simple à industrialiser qu’Apache selon nos experts. Son format de configuration est pour eux plus agréable et plus facile à manipuler que celui d’Apache, qui est un mélange de XML et de langage sérialisé. De nombreux interpréteurs spécialisés sont disponibles pour la configuration de NGINX, mais nous avons nous-même codé le nôtre, pour répondre au mieux à notre besoin propre.

De plus, NGINX implémente plusieurs fonctionnalités aidant à l’automatisation : par exemple, des mécanismes qui remontent de l’information à des services centralisés (Syslog par exemple), ou bien des modules exposant des API permettant de contrôler certains aspects du fonctionnement interne à NGINX, comme la gestion du cache. Cela évite de devoir créer ces services soi-même, et fait de NGINX un outil particulièrement adapté à l’industrialisation.

Serveur web et performance

Les considérations suivantes sont basées sur les capacités et le fonctionnement des solutions Nginx en version 1.2 et Apache en version 2.2 (version stables lorsque nos choix technologiques ont été faits).

Historiquement, NGINX est particulièrement reconnu pour ses bons résultats lors de tests de performance. Apache, en revanche, ne bénéficiait pas de la même réputation, au moins au moment où nous avons fait notre choix. Cela s’explique par plusieurs différences :

Lourdeur des processus

PoidsA chaque requête envoyée au serveur, un nouveau processus est lancé, que ce soit sur Apache ou NGINX. La différence ici se trouve dans le poids de ces processus (dans la configuration par défaut). Explication : pour servir des pages dynamiques, ces deux solutions font appel à des services externes, par exemple l’interpréteur PHP.

Pour cela, Apache utilise des modules internes (CGI, LDAP, PHP…). Pour chaque nouveau processus créé, ces modules sont chargés dynamiquement. Cela perd déjà du temps, car à chaque fois le programme vérifie quels modules doivent être chargés, et rend chaque processus particulièrement lourd. Sur NGINX, en revanche, les équivalents de ces modules ou, par défaut, les services CGI sont directement compilés dans la configuration de leurs solutions. Les processus NGINX sont donc beaucoup plus légers.

Imaginons maintenant que 90% du contenu d’un site est statique, et 10% est dynamique. Dans le cas d’un serveur web Apache, 100% des processus ont chargé les modules, qui sont pourtant inutilisés dans 90% des cas. On a donc de la mémoire mobilisée pour rien. Avec NGINX, les processus créés ont par défaut la capacité de fournir des fichiers statiques, et ce n’est que dans le cas des 10% restants que le serveur mobilisera les ressources nécessaires à l’interprétation d’une page dynamique (services externes). Ces ressources sont donc économisées dans 90% des cas.

C’est ainsi qu’à partir d’un certain nombre de visites sur un site, la différence de performance entre les deux solutions se fera de plus en plus sentir. Pour schématiser, si il faut 5 Go de mémoire pour servir une page statique et 15 Go de plus pour une page dynamique, voici la quantité de mémoire nécessaire pour chaque solution selon le nombre de visiteurs :

Apache NGINX
10 visiteurs 10x(5+15) = 200 Go 9×5 + 1x(5+15) = 65 Go
1 000 visiteurs 1 000x(5+15) = 20 000 Go 900×5 + 100x(5+15) = 500 Go

Fichiers htaccess

Apache fontionne avec des fichiers htaccess, ce qui n’est pas le cas de NGINX. Ce sont des fichiers de configuration « à la volée », qu’un développeur peut inclure dans son site. L’utilisation de ces fichiers a ses avantages, mais impacte négativement les performances. En effet, pour chaque requête reçue, Apache va vérifier tous les fichiers du site à la recherche d’un htaccess correspondant à sa requête, puis lire et interpréter ce fichier. Cela prend du temps et ralentit le site.

Il est cependant à noter que dernièrement, de nouveaux tests ont été effectués pour comparer les performances d’Apache et NGINX. Si NGINX gère plus rapidement les traitements de fichiers statiques, plus aucune différence n’a été observée concernant les fichiers dynamiques 1. Cela est dû au fait que depuis sa version 2.4, un seul processus Apache peut gérer plusieurs requêtes, ce qui le améliore grandement ses performances. La performance n’est donc plus un critère déterminant dans le choix entre ces deux solutions !

Serveur web et autonomie du client

Configuration iconeUn hébergeur infogérant comme NBS System a une responsabilité directe sur les systèmes de ses clients, et a les « pleins pouvoirs » (root) sur les machines. Il est donc impossible de donner le même niveau de contrôle à nos clients, ni même leur permettre de modifier facilement leurs configurations, afin d’éviter des conflits, des double interventions, etc.

Apache permet une délégation du contrôle des machines aux clients, qui sont alors plus autonomes, via les htaccess. En effet, un développeur n’a pas besoin de passer par l’hébergeur pour inclure un de ces fichiers de configuration sur son site, et peut les modifier comme il le souhaite. Cela permet d’éviter de longs échanges entre les deux entités, et gagne certainement du temps pendant l’exploitation.

NGINX ne fonctionne pas avec ces fichiers : toutes les modifications doivent être enregistrées en dur dans le fichier de configuration global de l’outil. Seul l’hébergeur peut faire cela, ni le développeur ni le client n’ont la main sur ce fichier. Il est cependant possible d’accorder des droits de modification à un client, via des consoles de contrôle. Cela permet au client d’avoir un certain niveau d’autonomie sur son site internet, tout en permettant à l’hébergeur de limiter la portée de cette autonomie à des modifications non dangereuses pour le fonctionnement du site en général.

Orientation des éditeurs

Les recommandations des éditeurs sont également à prendre en compte. En effet, certains de ces derniers ne fonctionnent pas, par exemple, sans htaccess : c’est le cas de Magento ou Prestashop. Ce dernier génère des fichiers htaccess à la volée, ce qui pose donc problème avec NGINX. Hybris, quant à lui, ne fournit pas de support si Apache n’est pas utilisé. Choisir NGINX dans ces conditions demande de la persévérance et des connaissances techniques.

Même si les éditeurs ont tendance à rester dans leur zone de confort avec Apache, cela s’estompe peu à peu : ils fournissent de plus en plus de procédures adaptées selon les différents types de serveurs.

Proximité psychologique

Apache NGINX logosAu-delà de tous ces critères pragmatiques de choix, comptent également les sentiments des équipes et le message véhiculé par le choix de sa solution. Pour NBS System, cela a fait pencher la balance vers NGINX : c’est une solution open source, simple et efficace, sans compter le fait que notre équipe compte parmi elle des développeurs de la solution (ils ont notamment créé le module NAXSI).

Alors, NGINX ou Apache ?

Comme nous l’avons dit dans la conclusion de notre article sur les solutions de reverse proxies, plus l’on avance dans le temps et moins les solutions présentent de différences majeures, si ce n’est quelques fonctionnalités spécifiques ; elles deviennent de plus en plus interchangeables. Depuis la version 2.4 d’Apache, cette tendance s’applique parfaitement à NGINX et Apache : à performances égales, restent comme critères de choix les préférences en termes d’industrialisation et d’autonomie client, ainsi que la proximité « émotionnelle » avec le produit.

Nous utilisons ainsi NGINX pour nos propres services web, ainsi que pour nos gros clients qui préfèrent la performance à l’autonomie. NGINX leurs servent à servir les fichiers statiques, et ce sont des fermes de PHP-FPM qui s’occupent des fichiers dynamiques. C’est cette scalabilité horizontale qui leur apporte une performance optimale avec peu d’utilisation de ressources. Pour la majorité de nos clients cependant, nous installons Apache, afin de leur fournir cette liberté et facilité de travail avec les éditeurs. Les solutions répondent ici au même besoin, mais avec des contraintes différentes !

1 Source : http://www.speedemy.com/apache-vs-nginx-2015/

Source technique : Denis Pompilio

Lucie Saunois
Lucie Saunois
Passionnée d'informatique, en particulier de sécurité, depuis qu'elle a rejoint l'OT Group en 2015, Lucie se spécialise dans la vulgarisation technique pour permettre à tous d'appréhender ces sujets parfois complexes.