Nginx contre Apache pour un site de contenu : arbitrage mesuré

La question revient à chaque projet et elle est souvent tranchée par habitude ou par ce que propose l'hébergeur. Les arguments échangés datent pour une bonne part du début des années deux mille dix, époque où l'écart de comportement entre les deux logiciels était considérable. Depuis, l'un a adopté un mode de fonctionnement bien plus efficace et l'autre s'est enrichi de fonctions qui lui manquaient, si bien que le choix se joue aujourd'hui sur d'autres critères que la performance brute. Nous reprenons donc le sujet à partir de ce qui se mesure réellement sur un site de contenu, en distinguant ce qui relève du logiciel de ce qui relève de sa configuration. Cette distinction est le cœur du sujet : l'immense majorité des écarts constatés en production s'expliquent par des réglages et non par le choix du produit. Les nommer permet de savoir quand la question mérite d'être posée et quand elle ne mérite pas une heure de réunion.

Ce que fait un serveur web, et ce qu'il ne fait pas

Le rôle du serveur web consiste à recevoir une requête, décider ce qu'il faut renvoyer, et le renvoyer. Pour un fichier statique, image ou feuille de style, il le lit sur le disque et l'envoie. Pour une page dynamique, il transmet la demande à un interpréteur, attend le résultat et le renvoie. Ce qui se passe dans l'interpréteur, c'est-à-dire l'essentiel du temps de traitement sur un site de contenu, ne dépend pas du serveur web. Les principes de fonctionnement de cette couche sont détaillés dans notre article sur le serveur web et son rôle.

Cette observation est décisive et elle est régulièrement perdue de vue. Sur une page produite par un système de gestion de contenu, le temps se répartit typiquement entre quelques millisecondes de traitement par le serveur web et plusieurs centaines de millisecondes d'exécution applicative et de requêtes en base. Changer de serveur web agit donc sur une fraction très minoritaire du total. Un site lent le reste après la migration, ce qui déçoit ceux qui en attendaient un remède. Le raisonnement vaut aussi dans l'autre sens : un site déjà rapide ne le devient pas moins en changeant de serveur, ce qui rend le risque faible et le bénéfice tout aussi faible. Avant d'engager une migration, il est donc utile de chiffrer la part du temps total effectivement attribuable au serveur web, ce qui se lit dans les journaux avec un champ de durée de traitement.

Le serveur web devient en revanche déterminant sur trois terrains : le service des fichiers statiques en grand nombre, la gestion d'un très grand nombre de connexions simultanées, et la mise en cache des pages produites. C'est sur ces trois points que le choix mérite une réflexion, et non sur la vitesse d'affichage d'une page isolée. Un quatrième cas, plus rare, concerne la diffusion de flux longs comme la vidéo ou les connexions maintenues ouvertes, où le modèle de traitement des connexions redevient déterminant. Sur un site de contenu classique, ce cas ne se présente pas.

Un quatrième terrain, souvent décisif en pratique, tient à la configuration. Le premier logiciel accepte des directives placées dans un fichier au sein de chaque répertoire, ce qui permet à une application ou à un utilisateur de modifier le comportement sans toucher à la configuration principale. Le second n'offre pas cet équivalent, toute modification passant par la configuration centrale et un rechargement. Cette différence structurelle a plus de conséquences pratiques que tous les écarts de performance réunis. Elle explique aussi pourquoi les hébergements mutualisés retiennent presque tous le premier : il permet à chaque client de régler son propre comportement sans intervention de l'hébergeur. Sur un serveur dédié à un seul site, cet avantage disparaît et il devient même un léger coût, chaque requête entraînant la lecture de ces fichiers dans l'arborescence.

Là où l'écart de performance existe encore

Le modèle de traitement des connexions constituait historiquement la différence majeure. L'un attribuait un processus ou un fil d'exécution à chaque connexion, ce qui consommait de la mémoire proportionnellement au nombre de visiteurs simultanés. L'autre traitait de nombreuses connexions dans un nombre fixe de processus, avec une consommation mémoire quasi constante. Sur mille connexions ouvertes, l'écart de mémoire pouvait atteindre un facteur dix.

Cette différence s'est considérablement réduite avec l'adoption par le premier d'un mode de fonctionnement événementiel comparable. Correctement configuré dans ce mode, il soutient aujourd'hui des charges du même ordre. Le problème est que la configuration par défaut de nombreuses distributions conserve l'ancien mode, ce qui explique la persistance de l'écart observé sur le terrain. Une bonne part de la supériorité constatée dans les tests provient donc d'une comparaison entre une configuration moderne et une configuration héritée. Vérifier le mode actif sur son propre serveur prend une commande et il n'est pas rare de découvrir le mode ancien sur une installation pourtant récente. Basculer vers le mode événementiel demande une adaptation de la façon dont l'interpréteur est appelé, ce qui constitue le seul travail réel de l'opération. Ce changement produit souvent le gain que l'on attendait d'une migration complète.

Sur le service des fichiers statiques, l'écart subsiste et il reste modeste sur les volumes courants. Un site servant quelques dizaines de fichiers par page ne verra pas de différence perceptible. Un site servant des milliers d'images ou de gros fichiers en téléchargement en verra une, de l'ordre de vingt à trente pour cent sur le débit soutenu. Ce terrain est aussi celui où un réseau de diffusion externe rend la question caduque, puisqu'il prend en charge ces fichiers avant même d'atteindre le serveur. Une fois cette couche en place, le serveur d'origine ne voit plus passer qu'une petite fraction des requêtes de fichiers, et l'écart mesuré sur ce poste devient sans objet. C'est l'une des raisons pour lesquelles le débat s'est apaisé ces dernières années.

Sur la mise en cache des pages produites, les deux logiciels disposent de mécanismes efficaces, avec des philosophies différentes. Le second intègre nativement un cache de réponses simple à configurer et très performant. Le premier s'appuie davantage sur des modules ou sur un cache applicatif placé en amont. Dans les deux cas, la présence d'un cache de pages change le comportement bien plus que le choix du logiciel, une page servie depuis le cache répondant en quelques millisecondes quelle que soit la solution. La vraie difficulté n'est jamais la mise en place du cache mais sa purge : savoir quelles pages invalider lorsqu'un contenu change, sans vider l'ensemble à chaque publication. Cette question se règle de la même façon quel que soit le serveur retenu, et elle mérite bien plus d'attention que le choix du produit.

Une comparaison honnête doit donc porter sur des configurations équivalentes et bien réglées, ce qui est rarement le cas des tests publiés. Les modalités d'un tel exercice, et les pièges qui faussent les résultats, sont abordés dans notre article sur la manière de faire un audit de serveur web.

Ce qui compte davantage que le choix du logiciel

Quatre réglages produisent, sur un site de contenu, un effet largement supérieur à celui du logiciel retenu, et ils s'appliquent aux deux.

Le premier est la présence d'un cache de pages. Un site dont chaque affichage déclenche une reconstruction complète, avec ses dizaines de requêtes en base, répond en trois cents à huit cents millisecondes. Le même site avec un cache de pages répond en dix à trente. Aucun changement de serveur web ne produit un écart de cette ampleur. C'est donc par là qu'il faut commencer, systématiquement.

Le deuxième est la compression des réponses textuelles. Une page de cent kilooctets se réduit à vingt-cinq avec une compression classique et à vingt avec un algorithme plus récent. Les deux serveurs proposent ces mécanismes et ils sont désactivés par défaut dans un nombre étonnant de configurations. La vérification prend dix secondes dans l'onglet réseau du navigateur, en regardant l'en-tête indiquant l'encodage de la réponse. Il faut penser à vérifier également que les fichiers de style et de script sont compressés, la configuration ne couvrant parfois que le HTML. Sur une page riche, l'oubli représente plusieurs centaines de kilooctets inutiles.

Le troisième est la configuration du cache navigateur pour les ressources statiques. Servir une image sans en-tête de conservation impose son retéléchargement à chaque visite. Une durée longue sur les fichiers dont le nom change en cas de modification supprime entièrement ce trafic. Ce réglage tient en trois lignes et il produit un effet immédiat sur les visites répétées. Il suppose que le nom des fichiers change lorsque leur contenu est modifié, mécanisme que la plupart des outils de construction assurent automatiquement. Sans cette empreinte dans le nom, une durée longue empêcherait les visiteurs de recevoir les corrections apportées.

Le quatrième est la version du protocole employée. Les versions récentes multiplexent plusieurs échanges sur une même connexion, ce qui supprime le coût des connexions multiples. Les deux serveurs les prennent en charge et cette prise en charge est parfois absente d'une configuration ancienne. L'incidence de ces réglages sur la visibilité d'un site est développée dans notre article sur le serveur web et le référencement.

Un site correctement réglé sur ces quatre points, quel que soit le logiciel, dépassera systématiquement un site mal réglé sur le logiciel réputé le plus rapide. Cette hiérarchie devrait guider l'ordre des chantiers, et elle est fréquemment inversée : on migre avant d'avoir configuré. L'ordre raisonnable consiste à régler ces quatre points, à mesurer, puis à se demander si un changement de serveur reste justifié. Dans la grande majorité des cas rencontrés, la question ne se pose plus une fois cette étape franchie.

Les critères qui font réellement pencher la balance

Le premier critère, presque toujours décisif, est ce que propose l'hébergement retenu. Sur une offre mutualisée, le choix n'existe pas et la question ne se pose donc que sur un serveur dédié ou un environnement en conteneur. Sur ces environnements, la disponibilité de compétences dans l'équipe compte davantage qu'un écart de performance marginal. Un serveur mal configuré par quelqu'un qui découvre sa syntaxe est plus lent et moins sûr qu'un serveur familier correctement réglé. Cette considération humaine est rarement écrite dans les comparatifs et elle détermine pourtant la fiabilité du site pendant des années. Elle vaut également pour la personne qui interviendra en urgence un dimanche soir, qui ne sera pas nécessairement celle qui a mis en place la configuration.

Le deuxième critère tient à la nature de l'application. Un système de gestion de contenu répandu fournit des règles de réécriture d'adresses prêtes à l'emploi pour le serveur historique, et les extensions écrivent leurs directives dans le fichier de répertoire. Migrer vers l'autre logiciel impose de traduire ces règles manuellement et de recommencer à chaque extension ajoutée. Ce coût de maintenance récurrent est le principal argument en faveur du statu quo sur ce type de site. Il se manifeste au pire moment : lors d'une mise à jour, quand une règle traduite manuellement des mois plus tôt ne correspond plus à ce que l'extension attend. Le symptôme est alors une fonction cassée sans message d'erreur explicite, et le diagnostic prend des heures.

Le troisième critère concerne la répartition des rôles. Une configuration très répandue place le serveur événementiel en frontal, chargé des fichiers statiques et du cache, et conserve l'autre derrière lui pour l'application. Cette combinaison cumule les avantages et elle ajoute une pièce à maintenir. Elle se justifie sur les sites à trafic important et constitue une complication inutile en dessous. Le seuil se situe approximativement à partir du moment où le serveur traite plusieurs dizaines de requêtes par seconde en pointe. En dessous, la pièce supplémentaire ajoute surtout un point de panne et une configuration à tenir à jour.

Le quatrième critère est la présence d'un réseau de diffusion externe. Lorsque les fichiers statiques et une partie des pages sont servis depuis un tel réseau, le serveur d'origine ne traite plus qu'une fraction du trafic. Son choix devient alors secondaire, la performance perçue dépendant principalement du réseau. Beaucoup de sites gagneraient davantage à mettre en place cette couche qu'à débattre du logiciel sous-jacent.

Le cinquième critère, souvent négligé, est la qualité de la documentation disponible pour les cas particuliers du site. Une redirection complexe, une protection d'un répertoire, une règle de cache conditionnelle : ces besoins se résolvent en quelques minutes lorsqu'on trouve un exemple et en plusieurs heures sinon. Le volume de ressources disponibles diffère selon le logiciel et selon la spécificité du besoin. Un besoin courant est également documenté des deux côtés, un besoin exotique beaucoup moins. Sur une équipe réduite, disposer d'exemples fiables pèse plus lourd qu'un gain de quelques millisecondes.

Comment mener la comparaison sur son propre site

La seule mesure qui vaille est celle effectuée sur le site concerné, avec ses contenus et son trafic réel. Les comparatifs généraux servent à comprendre les mécanismes, jamais à décider. La méthode consiste à préparer deux environnements identiques, à leur soumettre la même charge et à comparer trois indicateurs.

Le premier indicateur est le temps de réponse du serveur sur une page représentative, mesuré depuis un point extérieur et répété une centaine de fois. La médiane compte davantage que la moyenne, une seule requête lente faussant cette dernière. Il faut mesurer avec et sans cache de pages actif, les deux situations donnant des enseignements différents.

Le deuxième indicateur est le comportement sous charge. Un outil de simulation envoie un nombre croissant de requêtes simultanées jusqu'à ce que le temps de réponse se dégrade. Le point de rupture, exprimé en requêtes par seconde, révèle la capacité réelle. Ce test doit être mené sur l'environnement de préproduction et jamais en production, où il perturberait les visiteurs.

Le troisième indicateur est la consommation de mémoire à charge égale. Elle détermine le dimensionnement nécessaire et donc le coût mensuel de l'hébergement. Sur un petit serveur, cette contrainte est souvent celle qui limite en premier. Elle se relève avec les outils système standard pendant le test de charge.

Ces trois mesures prennent une demi journée à préparer et une heure à exécuter. Elles produisent une décision documentée plutôt qu'une préférence, et elles servent de référence lors des évolutions futures. Les outils nécessaires sont libres et largement documentés, et un poste de travail suffit à les faire tourner.

Ce que la migration coûte réellement

Une migration de serveur web n'est jamais une opération isolée : elle entraîne la traduction des règles de réécriture, la reprise des protections de répertoires, la revue des règles de cache et la vérification de chaque redirection existante. Sur un site installé depuis plusieurs années, ces éléments se comptent en dizaines et personne n'en tient la liste complète. Le premier travail consiste donc à les inventorier, ce qui prend généralement une journée et révèle des règles dont plus personne ne connaît l'objet.

Le deuxième poste de coût est la période d'instabilité qui suit la bascule. Les cas particuliers apparaissent au fil des jours : un formulaire qui échoue, un fichier de téléchargement inaccessible, une redirection oubliée qui renvoyait un trafic ancien. Ces incidents sont individuellement mineurs et leur accumulation mobilise une personne pendant une à deux semaines. Prévoir cette disponibilité fait partie du chiffrage honnête de l'opération.

Le troisième poste tient à la reprise des automatismes construits autour du serveur : renouvellement de certificats, rotation des journaux, surveillance, sauvegardes. Ces mécanismes sont invisibles tant qu'ils fonctionnent et leur défaillance se découvre plusieurs semaines plus tard, au pire moment. Les vérifier explicitement après la migration, plutôt que de les supposer fonctionnels, évite une mauvaise surprise le jour de l'expiration d'un certificat.

Ces trois postes réunis représentent couramment cinq à dix jours de travail sur un site de taille moyenne. Rapportés au gain attendu, qui se chiffre en quelques dizaines de millisecondes sur des pages déjà mises en cache, le calcul penche rarement en faveur de la migration. Il bascule en revanche lorsque la migration accompagne un changement d'hébergement déjà décidé, situation où le coût marginal devient faible.

La conclusion pratique est donc simple : sur un site de contenu existant, la question du serveur web arrive après celle du cache, de la compression, des en-têtes et du protocole. Sur un projet neuf, elle se tranche selon les compétences de l'équipe et l'écosystème de l'application. Dans les deux cas, elle mérite beaucoup moins d'attention que ne lui en accordent les discussions techniques.

Une recommandation pour finir

Une dernière recommandation : ne jamais migrer un serveur web et changer autre chose en même temps. Une migration accompagnée d'une mise à jour de la version de l'interpréteur ou d'un changement d'hébergeur rend toute attribution impossible. Si les mesures se dégradent, personne ne saura pourquoi. Séparer les changements allonge le calendrier et il constitue la seule façon d'apprendre quelque chose de l'opération.