Module 2 - Architectures
NGINX ou Apache, la question se pose
Déverrouiller le module

Après deux décennies de domination absolue, le serveur HTTP Apache perd de sa superbe et voit se dresser un concurrent redoutable, NGINX. A la fin septembre 2017, Apache représentait globalement 39 % du marché, contre 30 % à NGINX et 10 % à IIS. Ce n’est pas pour autant la fin de ce monument qu’est Apache. Mais c’est une question que se posent les professionnels LeMarson.

La très forte « html-isation » des applications induit la mise en place d’un serveur HTTP performant, adapté à toutes les formes de soumission, depuis les postes de travail classiques, jusqu’aux objets et mobiles.

Or, depuis de nombreuses années, le paysage restait figé, car à moins d’être inféodés à Microsoft et d’avoir perdu leur libre-arbitre, les utilisateurs avaient fait le choix systématique du serveur Web HTTP Apache, excellent au demeurant, plutôt que celui du triste IIS. Particulièrement fiable et performant, Apache a toujours rendu les services que l’on attendait de lui. Ce qui a largement contribué à forger une image d’excellence des projets de l’ensemble de la communauté qui porte son nom.

Ces temps sont cependant révolus. Car Apache créé en 1995 par Bob McCool est fondé sur une architecture, qui certes a fait sa fortune face à IIS, mais présente aujourd’hui quelques signes de faiblesse, quand les volumes de requêtes à traiter deviennent très importants, essentiellement quand elles aboutissent à des pages HTML statiques.

Plusieurs alternatives se sont levées, toujours Open Source, qui progressivement « mangent » Apache et prévoient de le dépasser dans les statistiques : NGINX et à un degré moindre lightlpd.

De manière superficielle on peut estimer que NGINX est très performant pour des charges statiques importantes et consomme moins de ressources, alors qu’Apache est mieux adapté aux requêtes dynamiques. Entendez par là des soumissions PHP, ASP.NET, Python, Ruby…

Alors, faut-il abandonner Apache et passer entièrement à NGINX ? Ou peut-on imaginer des solutions mixtes, chaque serveur étant exploité pour ses qualités intrinsèques et se partager une partie du trafic. C’est ce que nous vous proposons d’examiner dans ce dossier.

Les critères de choix

NGINX et Apache sont deux serveurs Web et à ce titre leur travail consiste à prendre en compte les requêtes HTTP qui leur arrivent des usagers et de les acheminer là où elles seront traitées. De la même manière, une fois le travail exécuté, ils retournent les résultats sous forme de pages HTML.

Leur fonction principale et c’est ce qui les différencie d’un serveur d’application type WebSphere ou WebLogic,  est donc entièrement axée sur la prise en compte des requêtes et réponses Web, mais pas sur leur traitement. C’est sur ce type de service que sera fondé par exemple une servlet Java dans une architecture MVC.

Il y aura ici deux contextes, selon que les pages HTML à traiter seront statiques, autrement dit des pages à contenu fixe ou dynamiques, lorsqu’elles seront générées par un moteur PHP, ASP.NET ou équivalent.

Autre critère important, celui du volume. Les serveurs n’ayant pas les mêmes comportements selon qu’ils auront à traiter quelques centaines de requêtes ou des millions.

La différence entre les deux serveurs est essentiellement de nature architecture, car ils ne « travaillent » pas de la même manière, les résultats se faisant sentir surtout pour les grosses configurations où les qualités et défauts de l’un et l’autre apparaissent clairement.

La différence entre process et thread

Pour bien aborder les différences entre les deux serveurs HTTP, il convient de rappeler celles qui existent entre un process et un thread, deux unités de traitement, qui ne se situent pas au même niveau d’exécution.

Un process est un programme qui s’exécute indépendamment des autres, effectue un certain travail en s’appuyant sur ses propres ressources : une pile d’exécution, un compteur ordinal, des registres et sa mémoire. Il ne peut pas accéder directement aux données gérées par d’autres process et la commutation d’un process à l’autre nécessite du temps, car il faut tout sauvegarder et repartir sur de nouvelles bases.

Un système d’exploitation est fondamentalement basé sur des processus, pour au moins une raison, leur indépendance et donc la possibilité d’isoler les traitements et les…pannes.

Un process est cependant un mécanisme lourd et encombrant.

Un thread, pour sa part, est une unité d’exécution, à l’intérieur d’un process. On dit souvent qu’il s’agit d’un process allégé, un process pouvant en contenir un certain nombre, qui ne sont pas indépendants.

Contrairement à un process, le thread partage la mémoire (« hype memory ») du process dans lequel il a été créé. Par contre, il peut communiquer facilement avec les autres threads, sans passer par un « utilitaire » spécialisé et surtout induit une charge système beaucoup plus faible.

Les modes multiprocess (MPM) d’Apache : « prefork » et « worker », le mode « event » étant une variante du worker et l’architecture NGINX.
Le fonctionnement d’Apache

Le serveur Apache est structurellement fondé sur des modules que l’architecte applicatif peur choisir et organiser, 122 actuellement, sans compter ceux qui ont été développés par des partenaires. C’est un point très important qui témoigne du dynamisme de l’écosystème. Ce à quoi ne peut pas prétendre NGINX, plus récent et dont la communauté est beaucoup plus restreinte.

En termes de performances, on peut organiser Apache « à la carte », le préconfigurer en fonction des besoins, grâce à trois modules distincts : MPM_prefork, MPM_worker et MPM_event.

Le mode MPM_prefork

Avec ce mode, l’utilisateur préconfigure son serveur et démarre de manière anticipée un certain nombre de process, sans thread. Il anticipe en quelque sorte sur la charge qu’il prévoit être la sienne.

Chacun des process est susceptible de répondre à une requête, sous contrôle d’un process parent unique, qui est une sorte de « grand ordonnanceur » et fonde sa stratégie d’ouverture des process enfants sur des directives systèmes : StartServers, MinSpareServers, MaxSpareServers et MaxRequestWorkers, auxquelles l’administrateur Apache a accès.

Sur le principe le mode MPM_prefork revient à prévoir un certain nombre de process ouverts par défaut, chacun deux étant destinés à accueillir une requête.

Ce sont ces directives qui précisent le nombre de process à démarrer, MaxRequestWorkers permettant par exemple d’augmenter le nombre de requêtes simultanées susceptibles d’être prises en charge par Apache, fixé par défaut à 256. Elles précisent également le nombre de process placés en attente, prêts à traiter une requête, de manière à éviter le temps nécessaire pour les créer et les mettre en place. Cette « fameuse » lourdeur de la commuation…

Une autre directive, MaxConnectionsPerChild contrôle la fréquence avec laquelle Apache recycle son organisation, sort les process les plus anciens et lance les nouveaux.

Le principal avantage du mode MPM_prefork est celui de la performance, tout au moins tant que l’on reste en dessous des limites prévues. Par contre, dès que l’on dépasse ce cadre, il est susceptible de s’effondrer. De plus, il est fortement consommateur de mémoire et peut même refuser les connexions au-delà d’un certain seuil. Il est manifestement destiné aux petits sites, pour lesquels l’optimisation d’Apache ne sera pas essentielle. Voire transparente.

Le mode MPM_worker

Dans ce mode, un process maître assure le lancement de process enfants, chacun d’eux comportant plusieurs threads (un nombre fixe, paramétrable par la directive ThreadsPerChild), susceptibles de prendre en charge une requête, mais aussi un thread d’écoute des demandes qui les affecte aux threads non sollicités.

Globalement, Apache vérifie régulièrement la situation des threads de chacun des process, le nombre des inactifs et la réorganise de manière à rester dans les limites des directives MinSpareThreads et MaxSpareThreads.

D’autres directives permettent de contrôler le fonctionnement de l’ensemble, le nombre de serveurs enfants par exemple (ServerLimit, MaxRequestWorkers).

Habituellement le process maître est démarré sur le port 80 en mode root (sous Unix), alors que les process enfants et les threads le sont avec des privilèges plus restreints.

S’il y a un grand nombre de requêtes entrantes, Apache MPM_Worker exploite le module « mutex-accept » pour sérialiser les connexions entrantes (directive Mutex), car il n’est pas pénalisé par la lourdeur des process. Il est plus souple, mais peut aussi poser des problèmes pour des configurations à forts volumes et très évolutives.

Le mode MPM_event

Il s’agit ici d’une variante de MPM_worker, destinée à augmenter le nombre de requêtes entrantes grâce à une répartition différente entre les tâches affectées aux threads d’écoute et aux threads de travail. Il présente aussi le (gros) avantage de traiter efficacement le cas des transactions longues asynchrones, l’un des avantages de NGINX, le problème dit du « keep alive », autrement dit des connexions persistantes.

Ainsi un client peut conserver une connexion ouverte après avoir lancé une requête et en lancer une nouvelle sur le même socket pour éviter d’initialiser une connexion TCP supplémentaire. En gros, on a ouvert un canal TCP et on cherche à l’utiliser pour lancer des requêtes en série, sans attendre que le serveur d’application ait répondu. Le problème est que le serveur HTTP Apache exige de bloquer un couple process/thread pour chaque demande en attente, sans possibilité de le détruire. C’est pour cela que le mode MPM_event comporte un thread d’écoute de tous les sockets, histoire de faire le tri entre ceux qui sont dans un état de connexion permanente, de ceux qui ont terminé leur travail et de ceux qui n’ont plus qu’une seule chose à faire, envoyer les données au client.

C’est ce mode event qui est activé par défaut sur les configurations modernes.

Les architectes s’apercevront très vite qu’en pratique, quand ils comparent Apache et NGINX, c’est ce mode qu’ils auront à considérer.

L’organisation NGINX

NGINX est plus récent (première release en 2004) qu’Apache et a été conçu par Igor Sysoey pour gérer un très grand nombre de connexions simultanées, plus de 10 000, grâce à une très faible consommation mémoire, mais cependant une forte adéquation pour les contenus statiques. Ce qui peut être considéré comme restrictif.

NGINX est un serveur basé sur les évènements, comme peut l’être lighttpd et très orienté vers les traitements asynchrones.

Structurellement il est conçu très différemment.

Il est basé sur un ensemble de process dits « workers », dont le nombre est établi à l’avance, à l’installation, de même que sur des modules, qui eux-aussi doivent être installés au départ, contrairement à Apache où la configuration est plus dynamique.

Habituellement sur un serveur multicoeur, un process worker correspond à un cœur (core), ce qui contribue à prédéterminer la configuration de base.

Autre différence par rapport à Apache, les process ne sont pas créés par un process maître appartenant à NGINX, mais par un process du noyau du système d’exploitation. C’est donc l’OS qui va jouer le rôle de dispatcher et va ouvrir un canal socket pour chacun des process worker.

Individuellement, un process worker est capable de traiter des milliers de requêtes et il se fonde pour cela sur une boucle d’exécution, le cœur de l’architecture, chaque boucle s’exécutant en parallèle, en jouant sur les configurations multicoeurs.

C’est cette boucle qui est basée sur les évènements et fonctionne de manière non bloquante en asynchrone. Il s’agit d’un thread qui fait en sorte, entre autre, de ne pas bloquer les ressources demandées par une requête, en attente de la fin d’exécution d’une tâche sur le serveur. La qualité et l’algorithme de traitement de la boucle événementielle sont pour beaucoup dans les performances constatées sur NGINX.

NGINX placé en frontal d’un serveur Apache : une configuration de plus en plus courante.
Apache ou NGINX

Manifestement Apache est en « pôle position » dès lors qu’il faut traiter un contenu dynamique.

Il dispose d’un support intégré qui renforce cette adéquation, pour PHP et Python, parmi les langages les plus utilisés dans ce type d’application. Une grande différence par rapport à NGINX.

Il peut bien entendu s’appuyer sur une énorme » panoplie de plus de 120 modules « maison, mais aussi sur un écosystème dynamique et continue pour l’instant à faire la « course en tête ».

On lui reconnaîtra une très bonne console d’administration et quelques artefacts séduisants, tels que l’usage des fichiers .htaccess, des fichiers de configuration, qui permettent de définir des règles d’accès dans un répertoire et ses sous-répertoires (il n’y a pas l’équivalent dans NGINX).

« Cerise sur le gâteau », Apache est jugé plus diversifié dans ses usages, ce dont témoignent ses configurations MPM.

A contrario, les usagers considèrent qu’il peut être trop consommateur de ressources.

NGINX pour sa part est réputé très adapté aux grosses demandes, les fameux C10k, mais présente aussi des atouts intéressants : une faible consommation mémoire, l’asynchronisme des traitements sur un seul thread, des capacités d’adaptation à d’autres fonctions, une empreinte système plus légère, une capacité d’évolutivité plus nette (scalability) et l’adéquation avec les serveurs qui s’exécutent en mémoire virtuelle.

On lui reprochera la taille de sa communauté, un panel de modules moins conséquent et son inadéquation avec les flux dynamiques.

En dehors de ses capacités propres, qui sont indéniables pour des contenus statiques, il arrive de plus en plus souvent que les architectes confient à NGINX des fonctions de « load balancing », cache, de serveur de streaming pour les flux vidéos, voire de « reverse proxy », mais aussi de frontal d’Apache.

On retrouve de plus en plus souvent ces configurations mixtes et c’est sans doute elles qui contribuent à ce sentiment global de forte poussée NGINX.

Selon W3Techs, un consultant qui suit depuis des années les positions d’Apache, NGINX mais aussi de IIS de Microsoft, les chiffres penchent en faveur de NGINX, qui a d’ores et déjà dépassé Apache sur le créneau du million de serveurs les plus sollicités. Chiffre confirmé à l’étage en-dessous des 100 000 serveurs les plus lourds. W3Trends ne fait pas de distinction entre les flux statiques et dynamiques, ce qui peut fausser la perception que nous en retenons.

Demain

Si l’on en croit les statistiques, l’avenir d’Apache est scellé et c’est NGINX qui va le supplanter. On peut donc en déduire qu’il faut envisager une migration massive. Sauf que ce n’est pas ce qui va se produire. Bien qu’Apache bénéficie toujours du très gros avantage de la communauté et d’un marché de modules qui ne faiblit pas, les architectes applicatifs pouvant y puiser ceux dont ils ont besoin, pour traiter des problématiques nouvelles, liées à des formes de requêtages originales : objets, mobiles, etc.

Pour ce qui est du produit, nous ne serons pas aussi affirmatifs que les observateurs « bien pensants », car il nous apparaît qu’Apache conserve d’indéniables atouts, y compris pour les configurations lourdes, voire multi-serveurs et que le déséquilibre apparent que l’on constate pour les très hauts débits statiques, pourrait se résorber avec l’arrivée des nouvelles versions. Et ce qu’il faudrait véritablement considérer ce sont les parts de marché de l’un et de l’autre pour LA fonction centrale de serveur HTTP et non pas de complément à une autre architecture.

En fait, ce n’est donc pas nécessairement le produit qui nous inquiète, face à NGINX, mais plutôt la communauté Apache elle-même et ce depuis l’épisode malheureux d’Open Office, qui a montré qu’elle n’était pas aussi indestructible qu’on le croyait et qu’elle-aussi subissait les aléas du marché et la disponibilité ou non des ressources de développement.

L’avenir nous semble plutôt fait d’une sorte de compromis à parts égales entre les deux acteurs, plutôt qu’une domination sans partage. A moins que l’une ou l’autre des communautés pour des raisons imprévisibles ne finisse par perdre pied. Ce qui est toujours possible.

Les configurations hybrides vont jouer un grand rôle dans les années à venir et c’est sur ce créneau d’ « assistant » que NGIX devrait continuer de progresser. Quant à Apache, sans doute l’un des plus extraordinaires produits de ces vingt dernières années, ceux qui le voient déjà mort et enterrés, pourraient avoir quelques surprises.

 
 

Plus de thématiques

 
Tendances : des choix structurants pour les datacenters en 2018
En 2018, la question à laquelle il nous faudra répondre, sera de définir le rôle .....
DSI, vous devriez vous intéresser à ONAP
Les architectures informatiques de réseaux sont passées d’équipements interconnect&...
802.11ax, le très haut débit pour Wi-Fi
Sur le principe, le Wi-Fi 802.11ax, que l’on appelle aussi High Efficiency WLAN (HEW), répond ......
2018 : la grande année du WAN
Trois grandes évolutions vont symboliser les réseaux d’entreprises en 2018 : la formi...
L’apport des micro-modules dans les datacenters
Bien que la transformation physique d’un datacenter ne soit plus aussi compliquée à effect...
Quel Linux pour Docker ?
Officiellement, les images containers sont supportées par deux familles d’OS : Linux et Wind...
Edge Computing, quelles opportunités pour les entreprises
Le fait de rapprocher les ressources de traitement au plus près des usagers est un ...
Les infrastructures « composables », l’avenir leur appartient
La tendance en matière d’infrastructure de datacenter, nous ne parlons pas ici de Cloud, est ...
Azure Stack pour contrer OpenStack
La dénomination Azure Stack parle d’elle-même. L’objectif de Microsoft est bien d&rsq...
L’adaptation des applications à Docker
La technologie Docker, proposée depuis quelques années par Solomon Hykes, un franco-améri...
Comprendre les mécanismes WaaS
Le moins que l’on puisse dire est que la nouvelle stratégie de Microsoft, WaaS (Windows ...
IBN, une étape majeure vers la programmation des réseaux
Dans la chronologie des évolutions, l’IBN constitue la 3 ème phase dans le cheminement ver...
L’avenir de votre réseau Wi-Fi haut-débit
Il y a encore peu de temps, Wi-Fi présentait 2 inconvénients : une distance de raccordement...
Ce que devient le « desktop » en 2017
Le temps n’est plus où il se vendait 320 millions de PC en une année. ...
Terminaux et desktops « virtualisés » : c’est long…
En matière de postes de travail, il n’y a que 4 solutions : le poste lourd ...
« will (insert upcoming year here) be the year of the Linux Desktop ? »
Cela fait 10 ans que l’on se dit qu’il serait temps de migrer le parc ...
Les concurrents de Docker : oui, ils existent…
2017 sera à l’évidence l’année des containers. Mais elle « risque&...

8 grands modules qui couvrent le monde des TI de manière exhaustive. Chacun contient des dizaines de dossiers de fond qui décryptent, analysent et critiquent objectivement les tendances.

Les tarifs

Prix US$/EU/CAD
1 an d'abonnement
1 module = 100 US$ / 100 € / 130 CAD
Pack 8 modules = 700 US$ / 700 € / 910 CAD