Apache vs NGINX - Qui GAGNE en termes de performances ?

Apache vs NGINX est l'un des débats les plus chauds (depuis la sortie de NGINX) car ils sont tous deux l'un des serveurs Web les plus courants au monde, suivis de LiteSpeed ​​et OpenLiteSpeed.

Apache et NGINX alimentent près de 60 % des sites Web mondiaux. Apache vs NGINX sont similaires en termes de performances et de fonctionnalités. Leur architecture, leur sécurité et leurs performances, en revanche, sont toutes différentes.

Il peut être difficile de choisir entre ces deux serveurs car ils sont tous les deux excellents. Étant donné que chaque serveur Web présente ses propres avantages et inconvénients, il est essentiel de choisir la meilleure option possible.

Vous pouvez également consulter le débat openlitespeed vs nginx ici.

Comparaison de vitesse entre Apache et NGINX

Avant de creuser profondément dans le débat Apache vs NGINX. Nous ferons d'abord un test de vitesse simple, où nous effectuerons des tests dans les scénarios suivants.

• Testons un petit fichier statique de 5 Ko
• Fichier statique de taille 1 Mo
• Tester une simple application PHP Hello World
• Analyse comparative Apache vs NGINX pour WordPress

Nous avons utilisé la même procédure pour tester openlitespeed vs nginx. OpenLiteSpeed ​​est vraiment une excellente alternative à NGINX car il prend également en charge les règles de réécriture .htaccess de base, vous pouvez donc facilement passer d'Apache à OpenLiteSpeed.

Testons un petit fichier statique de 5 Ko

Verdict final : Les deux serveurs ont fait la même chose avec un petit fichier statique.

apache

NGINX

Fichier statique de taille 1 Mo

Verdict final : NGINX a clairement gagné avec un gros fichier statique.

apache

NGINX

Tester une simple application PHP Hello World

Verdict final : Les deux serveurs ont fonctionné de la même manière avec l'application hello world php.

apache

NGINX

Analyse comparative Apache vs NGINX pour WordPress

Verdict final : NGINX a clairement gagné avec un site WordPress. Vous pouvez utiliser ce guide pour accélérer votre boutique WooCommerce

apache

NGINX

Résultat des tests - Apache vs NGINX

Comme nous pouvons le voir dans les tests, NGINX est relativement meilleur qu'Apache en termes de vitesse. Les résultats sont :

1. Testez un petit fichier statique de 5 Ko :

Dans ce test, nous voyons qu'Apache et NGINX donnent des résultats relativement identiques.

2. Testez un gros fichier statique de taille 1 Mo :

Dans ce test, nous voyons que la vitesse de NGINX est supérieure à celle d'Apache. NGINX offre un temps de réponse moyen beaucoup plus court.

3. Testez une simple application PHP Hello World

Dans ce test, nous constatons qu'Apache et NGINX donnent des résultats relativement identiques.

4. Testez Apache vs NGINX pour WordPress

Dans ce test, nous voyons que le temps de réponse moyen de NGINX est tellement inférieur à celui d'Apache lui donnant une vitesse supérieure à celle de NGINX.

apache

Il existe une communauté de développeurs qui maintiennent Apache en tant que serveur Web open source. Il utilise une architecture pilotée par processus où il crée un nouveau thread pour chaque demande de connexion.
De plus, Apache propose une variété de modules qui peuvent être utilisés pour augmenter les fonctionnalités de votre serveur Web. Apache est rapide, fiable, sécurisé et hautement personnalisable pour répondre aux besoins de différents environnements grâce à l'utilisation d'extensions et de modules.

Architecture de gestion des connexions

Apache dispose d'un certain nombre de modules multi-traitement (appelés MPM par Apache) qui contrôlent la manière dont les demandes des clients sont traitées. Essentiellement, cela permet aux administrateurs de changer rapidement l'architecture de gestion des connexions.

• mpm-Prefor : ce module de traitement multiple (MPM) implémente un serveur Web de pré-forking qui n'est pas fileté. Chaque processus serveur peut répondre aux requêtes entrantes et la taille du pool de serveurs est gérée par un processus parent. Il convient aux sites qui doivent éviter les threads afin de travailler avec des bibliothèques qui ne sont pas thread-safe. C'est également le meilleur MPM pour isoler chaque demande, garantissant qu'un problème avec l'un n'affecte pas les autres.
• mpm-worker : un serveur hybride multi-processus multi-thread est implémenté par ce module multi-traitement (MPM). Il peut traiter un grand nombre de requêtes avec moins de ressources système qu'un serveur basé sur des processus, car il utilise des threads pour livrer les requêtes. En gardant de nombreux processus disponibles, chacun avec de nombreux threads, il conserve une grande partie de la stabilité d'un serveur basé sur des processus.
• mpm-event : L'événement Multi-Processing Module (MPM) est destiné à permettre à plusieurs requêtes d'être traitées en même temps en déléguant certains traitements aux threads d'écoute, libérant ainsi les threads de travail pour servir de nouvelles requêtes.
  Apache a une conception flexible qui vous permet de choisir parmi une variété d'algorithmes de connexion et de traitement des demandes. Comme le paysage Internet a changé, les choix présentés sont principalement le produit de l'évolution du serveur et de la demande accrue de simultanéité.

Contenu statique ou dynamique

Le contenu statique peut être géré par les serveurs Apache à l'aide de leurs mécanismes standard basés sur des fichiers. Les approches MPM mentionnées ci-dessus sont principalement responsables de la performance de ces procédures.

Apache peut en outre traiter du contenu dynamique en incluant un processeur spécifique au langage dans chacune de ses instances de travail. Cela lui permet d'exécuter du contenu dynamique sans utiliser de composants externes au sein du serveur Web. Des modules chargeables dynamiquement peuvent être utilisés pour activer ces processeurs dynamiques.

Parce qu'Apache peut gérer le contenu dynamique en interne, la configuration du traitement dynamique est généralement plus simple. Les modules peuvent facilement être échangés si les exigences de contenu changent, et la communication n'a pas besoin d'être coordonnée avec un logiciel supplémentaire.

Configuration distribuée ou centralisée

En analysant et en interprétant les directives dans les fichiers cachés dans les dossiers de contenu eux-mêmes, Apache ajoute une option pour permettre une configuration supplémentaire sur une base par répertoire. Les fichiers .htaccess sont le nom de ces fichiers.

Étant donné que ces fichiers sont situés dans les dossiers de contenu, Apache recherche un fichier .htaccess dans chaque composant du chemin d'accès au fichier demandé et applique les directives qui s'y trouvent. Cela permet effectivement une configuration de serveur Web décentralisée, qui est couramment utilisée pour les réécritures d'URL, les limitations d'accès, l'autorisation et l'authentification, et même les politiques de cache.

Bien que tous les exemples précédents puissent être configurés dans le fichier de configuration principal d'Apache, les fichiers .htaccess offrent un certain nombre d'avantages. Premièrement, parce qu'ils sont évalués à chaque fois qu'ils sont rencontrés le long d'un chemin de requête, ils sont mis en œuvre sans nécessiter de rechargement du serveur. Deuxièmement, il permet aux utilisateurs non privilégiés de contrôler des parties spécifiques de leur propre contenu Web sans leur donner une autorité complète sur le fichier de configuration.

Certains logiciels Web, tels que les systèmes de gestion de contenu, peuvent désormais facilement personnaliser leur environnement sans avoir besoin d'accéder au fichier de configuration central. Les fournisseurs d'hébergement partagé l'utilisent pour garder le contrôle de la configuration de base tout en offrant aux clients l'accès à leurs répertoires spécifiques.

Fichier vs. Interprétation basée sur l'URI

Apache peut interpréter une demande soit comme une ressource physique du système de fichiers, soit comme une destination URI qui nécessite une évaluation plus abstraite. En général, Apache utilise les blocs <Directory> ou <File> pour le premier, tandis que les blocs <Location> sont utilisés pour des ressources plus abstraites.

Parce qu'Apache a été conçu dès le départ pour être un serveur Web, il interprète les requêtes comme des ressources de système de fichiers par défaut. Pour trouver un fichier réel, il commence par la racine du document et ajoute la partie de la demande après l'hôte et le numéro de port. Sur le Web, la hiérarchie du système de fichiers est essentiellement représentée par l'arborescence des documents disponibles.

Lorsque la demande ne correspond pas au système de fichiers sous-jacent, Apache propose un certain nombre d'options. Une directive Alias, par exemple, peut être utilisée pour mapper à un endroit différent. L'utilisation de blocs <Location> au lieu du système de fichiers vous permet de travailler directement avec l'URI. Des variantes d'expressions régulières sont également disponibles pour appliquer la configuration de manière plus flexible sur l'ensemble du système de fichiers.

Bien qu'Apache puisse fonctionner à la fois sur le système de fichiers sous-jacent et sur l'espace Web, il préfère utiliser des techniques de système de fichiers. Certaines des décisions de conception reflètent cela, comme l'utilisation de fichiers .htaccess pour la configuration par répertoire.

Module

Le système de modules d'Apache vous permet de charger et de décharger dynamiquement des modules pour répondre à vos besoins pendant que le serveur est en cours d'exécution. Le noyau Apache est toujours présent, mais les modules peuvent être activés ou désactivés, ajoutant ou supprimant des fonctionnalités et se connectant au serveur principal.

Cette fonctionnalité est utilisée par Apache pour un large éventail de tâches. En raison de la maturité de la plate-forme, elle est livrée avec une grande bibliothèque de modules. Mod php, par exemple, intègre un interpréteur PHP dans chaque worker en cours d'exécution et peut être utilisé pour modifier certaines parties des fonctionnalités essentielles du serveur.

D'un autre côté, les modules ne se contentent pas de gérer le contenu dynamique. Ils peuvent réécrire les URL, authentifier les clients, renforcer le serveur, enregistrer, mettre en cache, compresser, proxy, restreindre le débit et chiffrer les données, entre autres fonctions. Ils peuvent offrir des fonctionnalités améliorées sans ajouter beaucoup de travail.

Support, Compatibilité, Écosystème et documentation

Parce qu'Apache existe depuis si longtemps, il y a beaucoup de support pour cela. Pour le serveur principal et les situations basées sur des tâches impliquant la connexion d'Apache à d'autres logiciels, il existe une bibliothèque substantielle de documentation de première et tierce partie accessible.

De nombreux outils et projets Web contiennent des outils pour s'amorcer dans un environnement Apache, en plus de la documentation. Cela peut être fourni dans les projets eux-mêmes ou dans les packages que l'équipe de packaging de votre distribution gère.

En raison de sa part de marché et de la durée de sa disponibilité ; Apache recevra plus de support des projets tiers en général. Les administrateurs sont également plus susceptibles d'avoir travaillé avec Apache, non seulement en raison de son utilisation généralisée, mais aussi parce que de nombreuses personnes commencent leur carrière dans des environnements d'hébergement partagé, où Apache est pratiquement uniquement utilisé en raison des fonctionnalités de gestion distribuée .htaccess .

Avantages d'Apache par rapport à NGINX

De nombreux webmasters et développeurs préfèrent Apache à NGINX car il est beaucoup plus ancien. Il est compatible avec les systèmes d'exploitation Windows, Unix et Linux.

• Pour servir du matériel dynamique, il s'agit d'une excellente performance.
• Charger et décharger dynamiquement les modules.
• Fournit un fichier .htaccess par répertoire qui peut être utilisé pour remplacer les paramètres à l'échelle du système.
• Le support et la documentation sont exceptionnels.
• Le modèle utilise une approche à une connexion par processus.
• Il inclut les modules mod_evasive et mod_security, qui ajoutent une couche de sécurité supplémentaire.

Inconvénients d'Apache par rapport à NGINX

• Impossible de traiter un grand nombre de demandes en même temps.
• Par rapport à NGINX, l'affichage de contenu statique prend plus de temps.
• Il offre des capacités étendues de configuration et de gestion. Par conséquent, il ne convient pas aux novices.
• Les sites Web avec beaucoup de trafic ont des problèmes de performances.

NGINX

Pour tenter de résoudre le problème « C10k », le codeur russe Igor Sysoev a inventé NGINX. Igor a atteint son objectif : NGINX peut facilement gérer plus de 10 000 connexions simultanées. Pour mieux gérer les nouvelles connexions, NGINX a une conception événementielle et asynchrone. NGINX est un serveur Web qui offre de nombreuses fonctionnalités. Voici quelques-uns d'entre eux :

• Un cache HTTP et un équilibreur de charge
• Proxy frontal d'Apache et d'autres serveurs Web.
• Les protocoles HTTP, HTTPS, SMTP, POP3 et IMAP sont tous servis par ce serveur proxy inverse.

Depuis sa sortie, NGINX a gagné en popularité en raison de sa faible utilisation des ressources et de sa capacité à évoluer efficacement sur du matériel à faible coût. NGINX est un serveur Web spécialisé dans la fourniture rapide de matériel statique et conçu pour transférer les requêtes dynamiques vers un logiciel mieux adapté à ces tâches.

Architecture de gestion des connexions

NGINX est arrivé sur les lieux après Apache, avec une meilleure compréhension des problèmes de concurrence auxquels les sites à grande échelle seraient confrontés. NGINX a été construit à partir de zéro en utilisant un algorithme de gestion de connexion asynchrone, non bloquant et piloté par les événements pour tirer parti de ces informations.

NGINX génère des processus de travail, chacun étant capable de gérer des dizaines de milliers de connexions. Les processus de travail y parviennent en développant un mécanisme de boucle rapide qui vérifie et traite les événements de manière régulière. En dissociant le travail réel des connexions, chaque travailleur peut se concentrer sur une connexion uniquement lorsqu'un nouvel événement s'est produit.

Chacune des connexions du travailleur est placée dans la boucle d'événements, où elle coexiste avec d'autres connexions. Les événements sont traités de manière asynchrone dans la boucle, ce qui permet d'effectuer le travail de manière non bloquante. Le lien est supprimé de la boucle après sa fermeture.

NGINX peut évoluer exceptionnellement loin avec un minimum de ressources grâce à sa méthode de traitement des connexions. Étant donné que le serveur est monothread et qu'aucun processus supplémentaire n'est généré pour gérer chaque nouvelle connexion, l'utilisation de la mémoire et du processeur reste relativement constante, même lorsque le serveur est soumis à une pression intense.

Contenu statique ou dynamique

NGINX n'a ​​pas de support natif pour le traitement de contenu dynamique. NGINX doit transmettre PHP et d'autres demandes de contenu dynamique à un processeur externe pour traitement, puis attendre que le contenu rendu soit renvoyé. Le client peut alors être informé des résultats.

Pour les administrateurs, cela implique que la communication entre NGINX et le processeur doit être configurée à l'aide de l'un des protocoles compris par NGINX (http, FastCGI, SCGI, uWSGI, memcache). Cela peut rendre les choses un peu plus compliquées, notamment lors de l'estimation du nombre de connexions à autoriser, car chaque appel au processeur nécessitera une nouvelle connexion.

Cette stratégie, en revanche, offre quelques avantages. La surcharge de l'interpréteur dynamique ne sera présente que pour le matériel dynamique car il n'est pas inclus dans le processus de travail. Le contenu statique peut être envoyé de manière simple, l'interprète étant consulté uniquement lorsque cela est nécessaire. Ceci est également possible avec Apache, mais cela élimine les avantages mentionnés dans la section précédente.

Configuration distribuée ou centralisée

NGINX ne comprend pas les fichiers .htaccess et n'a aucun moyen d'évaluer la configuration par répertoire en dehors du fichier de configuration principal. Bien que moins polyvalente que l'approche Apache, elle présente ses propres avantages.

L'augmentation des performances est le gain le plus notable par rapport à l'approche .htaccess de la configuration au niveau du répertoire. Pour chaque demande, le serveur vérifiera ces fichiers dans chacun des répertoires parents menant au fichier demandé dans une configuration Apache standard qui autorise .htaccess dans n'importe quel répertoire. Si cette recherche fait apparaître un ou plusieurs fichiers .htaccess , ils doivent être lus et traités. NGINX peut traiter les requêtes plus rapidement en exécutant une seule requête de répertoire et en lisant un fichier pour chaque requête en n'autorisant pas les remplacements de répertoire (en supposant que le fichier se trouve dans la structure de répertoire conventionnelle).

Un autre avantage est qu'il est sécurisé. La distribution de l'accès à la configuration au niveau du répertoire répartit également les responsabilités de sécurité entre les utilisateurs individuels, qui peuvent ou non être dignes de confiance pour le faire correctement. En vous assurant que l'administrateur a un contrôle total sur le serveur Web, vous pouvez éviter plusieurs erreurs de sécurité qui pourraient survenir lorsque l'accès est accordé à d'autres.

Si ces problèmes vous préoccupent, gardez à l'esprit que vous pouvez désactiver l'interprétation .htaccess dans Apache.

Interprétation basée sur fichier VS URI

NGINX a été conçu pour fonctionner comme un serveur Web ainsi que comme un serveur proxy. Il fonctionne en grande partie avec des URI, traduisant vers le système de fichiers si nécessaire, en raison de l'architecture requise pour ces deux tâches.

Cela peut être vu dans la façon dont les fichiers de configuration NGINX sont construits et traités dans certains cas.
NGINX n'a ​​pas de moyen de spécifier la configuration d'un répertoire de système de fichiers, il analyse donc l'URI.

Les blocs de serveur et d'emplacement, par exemple, sont les blocs de configuration les plus importants pour NGINX. Le bloc serveur est chargé d'interpréter l'hôte demandé, tandis que les blocs de localisation sont chargés de faire correspondre des parties de l'URI après l'hôte et le port. La demande est maintenant traitée comme un URI plutôt que comme un emplacement de système de fichiers.

Toutes les demandes de fichiers statiques doivent éventuellement être mappées à un emplacement sur le disque. NGINX sélectionne le serveur et les blocs d'emplacement qui traiteront d'abord la demande, puis combine la racine du document avec l'URI, en modifiant si nécessaire en fonction des paramètres.

Cela peut sembler similaire, mais l'interprétation des demandes en grande partie comme des URI plutôt que comme des emplacements de système de fichiers permet à NGINX de servir plus facilement de serveur Web, de messagerie et proxy. NGINX est configuré en définissant comment il doit répondre à certains modèles de requête. NGINX n'inspecte pas le système de fichiers tant qu'il n'est pas prêt à livrer la demande, c'est pourquoi les fichiers .htaccess ne sont pas pris en charge.

Modules

NGINX a également un système de modules, mais il est considérablement différent de celui d'Apache. Les modules de NGINX ne peuvent pas être chargés dynamiquement, ils doivent donc être choisis et compilés dans le logiciel de base.
NGINX deviendra beaucoup moins adaptable pour de nombreux utilisateurs à la suite de cela. Cela est particulièrement vrai pour les utilisateurs qui hésitent à maintenir leur propre logiciel construit en dehors du schéma de conditionnement standard de leur distribution. Alors que la plupart des packages de distributions incluent les modules les plus couramment utilisés, si vous avez besoin d'un module non standard, vous devrez créer le serveur vous-même à partir des sources.

Les modules NGINX, en revanche, sont toujours très utiles car ils vous permettent de spécifier exactement ce que vous attendez de votre serveur en n'incluant que les fonctionnalités que vous souhaitez utiliser. Certains utilisateurs peuvent également penser que cette approche est plus sécurisée car des composants arbitraires ne peuvent pas être connectés au serveur. Si jamais votre serveur est mis dans une situation où cela est concevable, il est presque certainement déjà compromis.

La plupart des mêmes fonctionnalités sont disponibles dans les modules NGINX que dans les modules Apache. La prise en charge du proxy, la compression, la restriction de débit, la journalisation, la réécriture, la géolocalisation, l'authentification, le chiffrement, la diffusion en continu et les fonctions de messagerie sont toutes disponibles via les modules NGINX.

Support, Compatibilité, Écosystème et documentation

NGINX gagne en popularité à mesure que de plus en plus de personnes l'utilisent en raison de ses performances élevées, mais il a encore du rattrapage à faire dans certains domaines cruciaux.

Étant donné que la plupart des premiers développements et de la documentation étaient en russe, il était difficile de trouver une documentation substantielle en anglais pour NGINX dans le passé. La documentation a été étoffée au fur et à mesure que l'intérêt pour le projet a grandi, et il existe actuellement de nombreuses ressources d'administration disponibles sur le site NGINX et par des tiers.

Le support et la documentation pour les applications tierces sont de plus en plus disponibles, et les mainteneurs de packages commencent à proposer des options de configuration automatique d'Apache et de NGINX dans certaines circonstances. La configuration de NGINX pour qu'il fonctionne avec d'autres logiciels est généralement simple, même sans support, tant que les besoins du projet sont documentés (autorisations, en-têtes, etc.).

Avantages de NGINX

Le serveur Web NGINX est simple, léger et rapide. Conçu spécifiquement pour les sites Web à fort trafic.

• Utilise une architecture événementielle non bloquante qui utilise moins de CPU et de mémoire.
• Il comprend de nombreuses options d'optimisation et de diffusion pour le contenu statique. En conséquence, il sert du contenu statique 2,5 fois plus rapidement et utilise moins de mémoire qu'Apache.
• Il fonctionne admirablement dans un système multiprocesseur.
• Les attaques DDoS sont empêchées par une option de configuration intégrée.

Inconvénients de NGINX

• Le contenu dynamique ne peut pas être traité nativement.
• Un plus petit nombre de modules sont disponibles.
• Les systèmes d'exploitation Linux et Unix sont pris en charge, mais la prise en charge de Windows est limitée.
• Le fichier .htaccess , qui est pris en charge par Apache, n'est pas pris en charge par NGINX.
• Rareté des logiciels de surveillance des journaux - Enregistre simplement les journaux dans des fichiers qui doivent être parcourus manuellement.

Pour utiliser Apache et NGINX ensemble

Après avoir examiné les avantages et les inconvénients d'Apache et de NGINX, vous devriez être en mesure de déterminer quel serveur est le plus adapté à vos besoins. Cependant, de nombreux utilisateurs trouvent que l'utilisation simultanée des deux serveurs leur permet de tirer parti des avantages de chaque serveur.

La configuration standard de cette coopération consiste à utiliser NGINX comme reverse proxy devant Apache. Cela permettra à NGINX de traiter toutes les demandes des clients. Cela utilise la vitesse de traitement rapide de NGINX et sa capacité à gérer un grand nombre de connexions à la fois.

Les fichiers seront servis rapidement et directement au client pour le contenu statique, dans lequel NGINX excelle. NGINX transmettra les demandes de contenu dynamique, telles que les scripts PHP, à Apache, qui traitera les résultats et fournira la page rendue. Le matériel peut ensuite être retourné au client via NGINX.

Pour de nombreux utilisateurs, cette conception fonctionne bien car elle permet à NGINX d'agir comme une machine de tri. Il traitera toutes les demandes qu'il pourra et transmettra celles qu'il ne sait pas gérer. Nous pouvons réduire une partie du blocage qui se produit lorsqu'un processus ou un thread Apache est occupé en réduisant le nombre de requêtes que le serveur Apache est invité à gérer.

Vous pouvez évoluer avec cet arrangement en ajoutant plus de serveurs principaux si nécessaire. NGINX peut simplement être configuré pour transférer les requêtes vers un pool de serveurs, améliorant ainsi la tolérance aux pannes et les performances de la configuration.

Quand utiliser Apache vs NGINX ?

Apache et NGINX, comme décrit dans cet article, sont de bons serveurs Web puissants, adaptables et polyvalents. Pour les sites Web à fort trafic, Apache est le meilleur pour fournir du matériel dynamique, tandis que NGINX est le meilleur pour fournir du contenu statique ou des flux multimédias. C'est aussi simple que ça :

Quand pouvez-vous utiliser Apache

• Si vous êtes sur un plan d'hébergement mutualisé.
• Si vous appréciez une communauté serviable avec une multitude de ressources, c'est ici qu'il faut être.
• Apache est populaire parmi les développeurs Web car il est simple à configurer.

Quand pouvez-vous utiliser NGINX

• Si vous avez un VPS ou un serveur dédié.
• Vous êtes le propriétaire d'un site Web populaire avec beaucoup de contenu statique.
• Si vous souhaitez gérer le trafic entrant et le distribuer aux serveurs en amont qui sont plus lents.

Apache vs NGINX : lequel choisir pour votre serveur en 2022 ?

Celui que votre société d'hébergement fournit est celui que vous devez utiliser. Dans de nombreuses circonstances, vous n'aurez pas le choix. De nombreux fournisseurs Web suivent la même stratégie, que vous devriez suivre si vous hésitez entre Apache et NGINX :

• Apache est un bon choix si vous souhaitez héberger un serveur qui nécessite une configuration constante ou si vous souhaitez donner aux utilisateurs une option de configuration.
• NGINX, en revanche, est la voie à suivre si vous souhaitez des performances ultra-rapides, une sécurité à toute épreuve et la possibilité de gérer les configurations plutôt que vos utilisateurs.

En raison de son architecture fondamentale, Apache peut consommer plus de RAM en termes de performances. Dans les cas de trafic élevé, NGINX fonctionnera mieux, surtout s'il y a beaucoup de matériel statique à gérer.

NGINX peut donc être la solution idéale si vous comptez sur la mise en cache pour stocker et diffuser du contenu. N'oubliez pas que NGINX ne peut pas fournir de matériel dynamique ; par conséquent, vos performances seront affectées par l'efficacité du proxy utilisé par votre serveur.

Conclusion

Comme vous pouvez le voir, Apache ainsi que NGINX sont puissants, adaptables et capables. Évaluer vos besoins individuels et tester les modèles que vous attendez sont les principaux critères de sélection du serveur qui vous convient.

Parmi ces projets, il existe des différences significatives dans les performances brutes, les capacités et le temps nécessaire à la mise en œuvre de chacun. Souvent, cependant, ils sont le résultat d'une série de compromis qui ne doivent pas être ignorés. Enfin et surtout, il n'existe pas de serveur Web unique, alors choisissez l'option qui correspond à vos besoins.