Apache vs Ninx Performance: Techniques d'optimisation

Points clés

• Apache et Nginx sont tous deux des serveurs Web puissants, mais leurs fonctionnalités de performance varient; Apache adopte un modèle axé sur le processus, tandis que Nginx bénéficie d'une architecture axée sur les événements, ce qui le rend plus efficace pour gérer plusieurs connexions simultanées.
• Les optimisations clés d'Apache incluent le réglage des modules multi-processus (MPMS), tels que le préfuyage, le travailleur et l'événement pour gérer plus efficacement les connexions et la désactivation de .htaccess si possible pour réduire les performances du système de fichiers.
• Pour Nginx, les améliorations des performances clés incluent la définition du processus de travail et des connexions correct, en tirant parti des connexions Keepalive pour réduire les frais généraux TCP et en mettant en œuvre des politiques de mise en cache pour fournir du contenu plus rapidement.
• Les deux serveurs peuvent être encore optimisés en ajustant la configuration du matériel du serveur (comme l'ajout de RAM et l'utilisation de SSD) pour s'adapter aux besoins du processus de service Web.
• L'utilisation d'Apache et Nginx dans une configuration proxy inverse peut profiter des deux serveurs, Nginx gère le contenu statique et l'équilibrage de charge, tandis qu'Apache gère le contenu dynamique.
• La surveillance et les tests continus à l'aide de HTOP, de nouveaux logiciels de test de chargement et de charge spécifiques sont essentiels pour identifier efficacement les goulots d'étranglement et optimiser les performances du serveur.

Il y a quelques années, le serveur Web de la Fondation Apache (appelée "Apache") était si courant qu'il est devenu synonyme du mot "serveur Web". Son système de démon sur Linux est nommé httpd (signifie uniquement Http Process ) et est préinstallé dans la distribution Linux principale.

Il a été initialement publié en 1995 et a cité Wikipedia disant: "Il a joué un rôle clé dans le développement précoce du World Wide Web". Selon W3Techs, il s'agit toujours du logiciel de serveur Web le plus utilisé. Cependant, sa part de marché est en baisse sur la base des rapports qui montrent certaines tendances au cours de la dernière décennie et des comparaisons avec d'autres solutions. Netcraft et construit avec des rapports légèrement différents, mais les deux conviennent que la part de marché d'Apache est sur une tendance à la baisse, tandis que la part de marché de Nginx augmente.

nginx (prononcé moteur x ) a été publié par Igor Sysoev en 2004, avec son objectif clair de dépasser Apache. Le site Web de Nginx a un article à lire qui compare ces deux technologies. Au début, il a été principalement utilisé comme complément à Apache, principalement pour servir des fichiers statiques, mais il a augmenté régulièrement car il continue d'évoluer pour gérer diverses tâches de serveur Web.

Il est couramment utilisé comme proxy inversé, équilibreur de charge et cache HTTP. Les fournisseurs de streaming CDN et vidéo l'utilisent pour créer des systèmes de livraison de contenu qui sont essentiels à leurs performances.

Apache existe depuis longtemps et dispose de nombreux modules à choisir. La gestion des serveurs Apache est bien connue pour être conviviale. Le chargement dynamique du module permet à différents modules d'être compilés et ajoutés à la pile Apache sans recompiller le binaire du serveur principal. En règle générale, les modules seront dans le référentiel de distribution Linux, et après leur installation, ils peuvent être ajoutés à la pile avec élégance à l'aide de commandes de type A2enMod via le gestionnaire de package système. Nginx n'a pas encore vu cette flexibilité. Lorsque nous examinons le guide pour configurer Nginx pour prendre en charge HTTP / 2, le module est ce que Nginx doit construire - configuré au moment de la construction.

Une autre caractéristique qui contribue à la domination du marché Apache est le fichier .htaccess. C'est le tueur d'Apache, ce qui en fait la solution préférée pour les environnements d'hébergement partagés, car il permet de contrôler la configuration du serveur au niveau du répertoire. Chaque répertoire du serveur fourni par Apache peut avoir son propre fichier .htaccess.

nginx non seulement n'a pas de solution équivalente, mais empêche également cette utilisation en raison de l'impact des performances.

Part de marché du fabricant de serveurs de 1995 à 2005. Données de Netcraft

LiteSpeed ​​ou LSWS est un concurrent de serveur dont le niveau de flexibilité est comparable à Apache sans sacrifier les performances. Il prend en charge le .htaccess de style Apache, Mod_Security et Mod_rewrite, et mérite d'être envisagé pour partager des paramètres. Il est prévu en remplacement direct de l'Apache et peut être utilisé avec CPanel et Plesk. Il a pris en charge HTTP / 2 depuis 2015.

LiteSpeed ​​a trois niveaux de licence: OpenLitespeed, LSWS Standard et LSWS Enterprise. La norme et l'entreprise sont livrées avec une solution de mise en cache en option qui rivalise avec Varnish, Lscache, qui est intégré au serveur lui-même et peut être contrôlé à l'aide de règles de réécriture dans le fichier .htaccess (chaque répertoire). Il a également une "batterie" d'atténuation DDOS intégrée. Ceci combiné avec son architecture axée sur les événements en fait un concurrent solide, ciblant les fournisseurs d'hébergement axés sur les performances, mais il vaut la peine d'être mis en place même pour les petits serveurs ou sites Web.

Précautions matérielles

Lors de l'optimisation d'un système, nous ne pouvons pas trop insister sur l'attention sur les paramètres matériels. Quelle que soit la solution que nous choisissons pour la configuration, avoir suffisamment de RAM est crucial. Lorsqu'un processus de serveur Web ou un interprète comme PHP n'a pas assez de RAM, il commence à échanger et l'échange signifie en fait l'utilisation d'un disque dur pour reconstituer la mémoire de RAM. L'effet de cela est d'augmenter la latence chaque fois que cette mémoire est accessible. Cela nous rappelle le deuxième point - l'espace disque dur. L'utilisation du stockage SSD rapide est un autre facteur clé de la vitesse du site Web. Nous devons également faire attention à la disponibilité du processeur et à la distance physique entre le centre de données du serveur et le public cible.

Pour avoir une compréhension plus approfondie des aspects matériels du réglage des performances, Dropbox a un bon article.

Surveillance

Un moyen pratique de surveiller les performances de la pile de serveur actuelle en détail est HTOP, qui convient à Linux, Unix et MacOS et offre un aperçu coloré de nos processus.

Les autres outils de surveillance incluent une nouvelle relique (une solution avancée avec un ensemble complet d'outils) et NetData (une solution open source qui offre une excellente évolutivité, des mesures à grain fin et des tableaux de bord Web personnalisables pour la surveillance du système VPS et du réseau de serveurs). Il peut envoyer des alertes pour n'importe quel processus d'application ou système par e-mail, slack, pushbullet, télégramme, twilio, etc.

Monit est un autre outil open source sans tête qui surveille le système et peut être configuré pour nous alerter lorsque certaines conditions sont remplies, ou redémarrer certains processus, ou redémarrer le système.

Système de test

AB (Apache Benchmark) est un simple outil de test de charge de la Fondation Apache, et Siege est un autre programme de test de charge. Cet article explique comment les mettre en place, voici quelques conseils plus avancés sur AB, et une compréhension plus approfondie du siège peut être trouvée ici.

Si vous préférez l'interface Web, Locust est un outil basé sur Python qui est très pratique pour tester les performances du site Web.

Après l'installation de Locust, nous devons créer un fichier Locustfile dans le répertoire à partir duquel nous allons le lancer:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Ensuite, nous le démarrons à partir de la ligne de commande:

<code>locust --host=https://my-website.com
</code>

Un avertissement concernant ces outils de test de charge: ils ont pour effet des attaques DDOS, il est donc recommandé de limiter vos tests à votre propre site Web.

Ajustez Apache

Module MPM d'Apache

Apache remonte à 1995 et au début d'Internet, lorsqu'un moyen acceptable pour les serveurs de fonctionner a été de générer un nouveau processus sur chaque connexion TCP entrante et de répondre à elle. Si plus de connexions arrivent, davantage de processus de travail sont créés pour les gérer. Le coût de la génération de nouveaux processus est très élevé, et les développeurs d'Apache ont conçu un mode préfork où prépare un certain nombre de processus. Les interprètes de langage dynamique intégrés dans chaque processus (tels que MOD_PHP) sont toujours coûteux, et les paramètres par défaut d'Apache provoquent le plantage du serveur. Chaque processus ne peut traiter qu'une seule connexion entrante.

Ce modèle est appelé mpm_prefork_module dans le système MPM (module multi-processus d'Apache). Selon le site Web d'Apache, ce mode nécessite peu de configuration, car il peut s'autoréguler, et le le plus important, la directive MaxRequestworkers est suffisamment grande pour gérer autant de demandes simultanées que vous vous attendez à recevoir, mais suffisamment petite pour vous assurer Tous les processus ont suffisamment de RAM physique .

Un petit test de charge de locustes montrant un grand nombre de processus Apache générés pour gérer le trafic entrant.

Nous pouvons ajouter que ce modèle peut être la principale raison de la tristement célèbre réputation d'Apache. Il peut être inefficace des ressources.

La version 2.0 d'Apache apporte deux autres MPM qui essaient de résoudre le problème du mode Prefork . Ce sont Module de travail ou MPM_WORGE_MODULE et Module d'événements .

Le module de travail n'est plus basé sur les processus; Citer le site Web d'Apache:

Le processus de contrôle unique (processus parent) est responsable du démarrage du processus de l'enfant. Chaque processus d'enfant crée un nombre fixe de threads de serveur basé sur le nombre spécifié dans la directive ThreadsperChild, et un thread d'écoute qui écoute les connexions et les transmet au thread du serveur pour le traitement lorsque la connexion arrive.

Ce mode économise plus de ressources.

La version 2.4 d'Apache nous apporte le troisième module MPM - événement. Il est basé sur le MPM des travailleurs et ajoute un fil d'écoute séparé qui gère la connexion Sleepy Keepalive une fois la demande HTTP terminée. Il s'agit d'un mode asynchrone non bloquant avec une empreinte mémoire plus petite. Plus d'informations sur les améliorations de la version 2.4 sont ici.

Nous avons chargé un programme d'installation WooCommerce de test avec environ 1200 messages sur le serveur virtuel et l'avons testé sur Apache 2.4 avec le mode de préfigue par défaut et MOD_PHP.

Tout d'abord, nous l'avons testé en utilisant libapache2-mod-php7 et mmpm_prefork_module sur https://tools.pingdom.com:

Nous avons ensuite testé le module MPM de l'événement.

Nous devons ajouter Multiverse à notre /etc/apt/sources.list:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Ensuite, nous exécutons la mise à jour Sudo apt-get et installons libapache2-mod-fastcgi et php-fpm:

<code>locust --host=https://my-website.com
</code>

Étant donné que PHP-FPM est un service distinct d'Apache, il doit être redémarré:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Ensuite, nous avons désactivé le module de préfercbork et le mode événement activé et proxy_fcgi:

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>

Nous ajoutons cet extrait à notre hôte virtuel Apache:

<code>sudo service start php7.0-fpm
</code>

Ce port doit être cohérent avec la configuration PHP-FPM dans /etc/php/7.0/fpm/pool.d/www.conf. Plus d'informations sur les paramètres PHP-FPM sont là.

Ensuite, nous avons ajusté la configuration MPM_EVENT dans /etc/apache2/mods-available/mpm_event.conf, en nous rappelant que les mini-ressources VPS que nous avions pour ce test étaient limitées - nous avons donc juste réduit certains numéros par défaut. Détails de chaque directive sur le site Web d'Apache et conseils pour l'événement MPM ici. N'oubliez pas que les serveurs de démarrage consommeront une certaine mémoire, quelle que soit leur occupé. La directive MaxRequestworkers définit le nombre de demandes simultanées autorisées: la définition de maxconnectionsperchild à une valeur non nulle est importante car elle empêche les fuites de mémoire possibles.

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Ensuite, nous utilisons le service sudo apache2 redémarrer pour redémarrer le serveur (si nous modifions certaines directives, telles que ThreadLimit, nous devons arrêter explicitement et démarrer le service, en utilisant le service sudo apache2 stop; SUDO Service apache2 start).

Notre test sur Pingdom montre maintenant que le temps de chargement de la page a été réduit de plus de la moitié:

Autres conseils pour ajuster Apache:

Disable.htaccess: HTACCESS permet de configurer des configurations spécifiques pour chaque répertoire du répertoire racine du serveur sans redémarrer. Par conséquent, l'itération de tous les répertoires pour trouver le fichier .htaccess sur chaque demande entraînera des pertes de performances.

cité dans Apache Documentation:

D'une manière générale, le fichier .htaccess ne doit être utilisé que si vous n'avez pas l'autorisation d'accéder au fichier de configuration du serveur principal. … De manière générale, les fichiers .htaccess doivent être évités autant que possible. Vous pouvez faire la configuration que vous pensez souhaiter mettre dans le fichier .htaccess aussi efficacement que l'utilisation de la section dans le fichier de configuration du serveur principal.

La solution consiste à le désactiver dans /etc/apache2/apache2.conf:

<code>locust --host=https://my-website.com
</code>

Si nous en avons besoin pour un répertoire spécifique, nous pouvons l'activer dans la section du fichier hôte virtuel:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Les autres conseils incluent:

Utilisez Mod_expires pour contrôler le cache du navigateur - en définissant l'en-tête Expire.
Gardez HostNameLookups OFF - HostNameLookUps Off a été la valeur par défaut depuis Apache 1.3, mais assurez-vous qu'elle reste éteinte car elle peut entraîner des pertes de performances.
apache2buddy est un script simple que nous pouvons exécuter et obtenir les astuces pour ajuster le système: curl -sl
• https://www.php.cn/link/5b3a93d103a66345e5d404c61c5b5081 |

nginx

Nginx est un serveur Web axé sur les événements et non bloquant. Citez une affiche sur les actualités des pirates:

Les processus de fourniture sont très chers par rapport aux boucles d'événements. Le serveur HTTP basé sur des événements gagne finalement.

Cette déclaration a déclenché un débat assez intense sur les actualités des pirates, mais d'après notre expérience, le simple fait de passer de MPM_PREFORK Apache à Nginx signifie généralement empêcher les sites Web de s'écraser. Le simple fait de passer à Nginx est généralement une solution de contournement en soi.

Une explication visuelle plus complète de l'architecture Nginx peut être trouvée ici.

Paramètres nginx

Nginx recommande de fixer le nombre de travailleurs au nombre de cœurs PC (comme nous l'avons fait avec la configuration MPM_EVENT d'APACHE), en définissant Worker_Processes sur Auto dans /etc/nginx/nginx.conf (par défaut est 1).

Worker_Connections définit le nombre de connexions que chaque processus de travail peut gérer. La valeur par défaut est 512, mais elle peut généralement être augmentée.

La connexion Keepalive est l'aspect serveur qui affecte les performances, qui n'est généralement pas visible dans les repères.

Selon le site Web de Nginx:

La connexion HTTP Keepalive est une fonction de performance nécessaire qui réduit la latence et accélère le chargement de la page Web.

L'établissement d'une nouvelle connexion TCP peut être coûteux - sans parler de la situation impliquant Https cryptage. Le protocole HTTP / 2 atténue cela avec ses capacités de multiplexage. La réutilisation des connexions existantes peut réduire le temps de demande.

MPM_PREFORK d'Apache et MPM_Worker ont des restrictions de concurrence, ce qui contraste avec la boucle d'événement Keepalive. Ceci est fixé dans une certaine mesure dans le module MPM_EVENT d'APACHE 2.4 et apparaît comme le seul mode de fonctionnement par défaut dans Nginx. Le travailleur NGINX peut gérer des milliers de connexions entrantes en même temps, et si elle est utilisée comme proxy inverse ou équilibreur de charge, Nginx utilise un pool de connexion Keepalive local sans frais de connexion TCP.

keepalive_requests est un paramètre qui régule le nombre de demandes qu'un client peut faire via une seule connexion Keepalive. keepalive_timeout définit l'heure à laquelle la connexion Keepalive inactive reste ouverte.

keepalive est un paramètre lié à la connexion de Nginx à un serveur en amont - lorsqu'il agit comme un proxy ou un équilibreur de charge. Cela signifie le nombre de connexions en amont de Keepalive gratuites par processus de travailleur.

Activer les connexions Keepalive en amont nécessite de mettre ces instructions dans la configuration principale de Nginx:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

Les connexions en amont Nginx sont gérées par NGX_HTTP_UPSTREAM_MODULE.

Si notre application frontale continue d'interroger notre application back-end pour les mises à jour, l'augmentation de keepalive_requests et keepalive_timeout limitera le nombre de connexions qui doivent être établies. La directive Keepalive ne doit pas être trop grande pour permettre d'autres connexions à notre serveur en amont.

Les ajustements de ces paramètres sont basés sur la situation spécifique et doivent être testés. C'est peut-être l'une des raisons pour lesquelles Keepalive n'a pas de paramètre par défaut.

Utilisation de sockets Unix

Par défaut, Nginx utilise un processus PHP distinct pour transférer les demandes de fichiers PHP. Ici, il agit comme un proxy (tout comme lorsque nous configurons Apache avec PHP7.0-FPM).

Habituellement, nos paramètres d'hôte virtuels utilisant nginx sont les suivants:

<code>locust --host=https://my-website.com
</code>

Étant donné que FastCGI et HTTP sont des protocoles différents, les deux premières lignes transmettent certains paramètres et en-têtes vers PHP-FPM, tandis que la troisième ligne spécifie comment les demandes de proxy - via des prises de réseau locales.

Ceci est pratique pour la configuration multi-serveur, car nous pouvons également spécifier le serveur distant auquel les demandes doivent être proxyées.

Cependant, si nous hébergeons toute la configuration sur un seul système, nous devons utiliser une prise Unix pour se connecter au processus PHP d'écoute:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Les prises UNIX sont considérées comme ayant de meilleures performances que le TCP, et ce paramètre est considéré comme plus sûr. Vous pouvez trouver plus de détails sur ce paramètre dans cet article de Rackspace.

Cette astuce sur Unix Sockets fonctionne également pour Apache. Plus de détails sont là.

gzip_static: la vue générale sur les performances du serveur Web est de compresser nos ressources statiques. Cela signifie généralement que nous essaierons de faire des compromis et d'essayer de compresser uniquement les fichiers qui dépassent un certain seuil, car la compression de ressources dynamiquement sur chaque demande peut être coûteuse. Nginx a une directive GZIP_STATIC qui nous permet de fournir une version GZIP du fichier (extension .gz), au lieu d'une ressource régulière:

<code>from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    @task(1)
    def index(self):
        self.client.get("/")

    @task(2)
    def shop(self):
        self.client.get("/?page_id=5")

    @task(3)
    def page(self):
        self.client.get("/?page_id=2")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 300
    max_wait = 3000
</code>

De cette façon, Nginx essaiera de fournir un style.css.gz au lieu de style.css (dans ce cas, nous devons gérer nous-mêmes).

De cette manière, les cycles du CPU ne sont pas gaspillés sur la compression dynamique pour chaque demande.

Cache avec nginx

L'histoire de Nginx est incomplète sans mentionner comment mettre en cache le contenu. La mise en cache Nginx est si efficace que de nombreux administrateurs système pensent qu'une couche de cache HTTP distincte (comme le vernis) n'a pas beaucoup de sens. "La simplicité est une caractéristique." Activer la mise en cache Nginx est très simple.

<code>locust --host=https://my-website.com
</code>

Il s'agit de la directive que nous plaçons dans le fichier hôte virtuel, situé à l'extérieur du bloc serveur. Le paramètre proxy_cache_path peut être n'importe quel chemin que nous voulons stocker le cache. Les niveaux spécifient le nombre de niveaux de répertoire que Nginx devrait stocker le contenu mis en cache. Pour des raisons de performance, deux niveaux sont généralement OK. Cela peut prendre du temps pour traverser le répertoire. Le paramètre KEYS_ZONE est le nom de la zone de mémoire partagée utilisée pour stocker les touches de cache, et 10m est l'espace pour ces touches en mémoire (10 Mo est généralement suffisant; ce n'est pas l'espace pour le contenu en cache réel). Max_Size est facultatif, ce qui définit la limite supérieure du contenu en cache - voici 10 Go. S'il n'est pas spécifié, il occupera tout l'espace disponible. Inactif spécifie combien de temps le contenu peut rester dans le cache avant sa demande, puis supprimé par Nginx.

Après le réglage, nous ajouterons la ligne suivante contenant le nom de la zone de mémoire au serveur ou au bloc d'emplacement:

<code>deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu xenial partner</code>

Les niveaux supplémentaires tolérants aux pannes de Nginx peuvent être implémentés en disant à Nginx de fournir des éléments à partir du cache lorsqu'une erreur se produit dans le serveur source, le serveur en amont ou les temps d'arrêt du serveur:

<code>sudo apt-get install libapache2-mod-fastcgi php7.0-fpm
</code>

Pour plus de détails sur le serveur ou les instructions de bloc d'emplacement pour modifier davantage le cache Nginx, voir ici.

Proxy Cache Les directives sont utilisées pour les ressources statiques, mais nous voulons généralement mettre en cache la sortie dynamique de notre application Web, qu'elle soit CMS ou autre chose. Dans ce cas, nous utiliserons la directive fastcgi cache au lieu de proxy cache *:

<code>sudo service start php7.0-fpm
</code>

La dernière ligne ci-dessus définira l'en-tête de réponse pour nous dire si le contenu est passé du cache ou non.

Ensuite, dans notre serveur ou notre bloc d'emplacement, nous pouvons définir quelques exceptions de cache - par exemple, lorsqu'une chaîne de requête existe dans l'URL de la demande:

<code>sudo a2dismod php7.0 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi
</code>

Aussi, dans le cas de PHP, dans le bloc .php dans le serveur, nous ajouterons quelque chose comme les suivants:

<code><filesmatch>
    SetHandler "proxy:fcgi://127.0.0.1:9000/"
</filesmatch></code>

Ci-dessus, FastCGI_CACH * Lignes et FastCGI_NO_CACH REGLEMENT CACHING ET EXCLUSION. Une référence détaillée à toutes ces instructions peut être trouvée sur le site Web de documentation NGINX.

Pour en savoir plus, le personnel de Nginx a fourni un webinaire gratuit sur ce sujet et il y a beaucoup de livres électroniques disponibles.

Conclusion

Nous essayons d'introduire certaines technologies qui aident à améliorer les performances du serveur Web et les théories derrière elles. Mais ce sujet n'est en aucun cas exhaustif: nous ne couvrons toujours pas les paramètres proxy inverses ou les paramètres multi-server composés d'Apache et de Nginx. Les meilleurs résultats sur les deux serveurs dépendent du test et de l'analyse des cas réels spécifiques. Ceci est un sujet sans fin.

FAQ sur Apache et Nginx Performance Optimization Technology

Quelle est la principale différence entre Apache et Nginx en termes de performances et d'optimisation?

Apache et Nginx sont tous deux des serveurs Web puissants, mais il existe des différences significatives dans les capacités de performances et d'optimisation. Apache est un serveur plus ancien qui utilise un modèle axé sur le processus pour créer un nouveau thread pour chaque demande. Cela peut conduire à une grande quantité d'utilisation de la mémoire lorsqu'il s'agit de plusieurs connexions simultanées. Nginx, en revanche, utilise une architecture motivée par des événements qui lui permet de gérer des milliers de connexions simultanément, avec très peu d'utilisation de la mémoire. Cela rend Nginx plus efficace et plus rapide, en particulier dans la livraison de contenu statique et les scénarios proxy inversés.

Comment optimiser Nginx pour de meilleures performances?

Il existe plusieurs façons d'optimiser Nginx pour de meilleures performances. Tout d'abord, vous pouvez ajuster le processus des travailleurs et la connexion des travailleurs. Le processus de travailleur doit être défini sur le nombre de processeurs ou de cœurs, tandis que la connexion du travailleur doit être définie sur la limite maximale du fichier ouvert. Deuxièmement, vous pouvez permettre à la compression GZIP de réduire la taille des données que Nginx envoie au client. Troisièmement, vous pouvez utiliser le cache pour stocker des données fréquemment accessibles en mémoire, en réduisant les opérations d'E / S de disque. Enfin, vous pouvez utiliser l'équilibrage de charge pour répandre le trafic réseau sur plusieurs serveurs, améliorant le temps de réponse et les performances globales.

Comment optimiser Apache pour de meilleures performances?

Apache peut être optimisé de diverses manières. Tout d'abord, vous pouvez ajuster la directive MaxClients pour contrôler le nombre maximum de connexions simultanées. Deuxièmement, vous pouvez permettre à mod_deflate de compresser les données avant de l'envoyer au client, réduisant ainsi l'utilisation de la bande passante. Troisièmement, vous pouvez utiliser MOD_CACH pour le cache pour stocker les données fréquemment accessibles en mémoire, réduisant les opérations d'E / S disque. Enfin, vous pouvez charger l'équilibrage à l'aide de mod_proxy_balancer pour diffuser le trafic réseau sur plusieurs serveurs, améliorant le temps de réponse et les performances globales.

Puis-je utiliser Apache et Nginx en même temps?

Oui, vous pouvez utiliser Apache et Nginx dans vos paramètres de proxy inverse. Dans cette configuration, Nginx agit comme le serveur frontal qui gère les demandes du client, et Apache agit comme le serveur back-end qui gère ces demandes. Cette configuration combine les avantages des deux serveurs, Nginx gère efficacement le contenu statique, tandis qu'Apache fournit un traitement de contenu dynamique.

Comment Nginx gère-t-il le contenu statique et dynamique de différentes manières?

nginx excelle dans la fourniture de contenu statique en raison de son architecture axée sur les événements, ce qui lui permet de gérer simultanément des milliers de connexions simultanées avec une utilisation minimale de la mémoire. Pour le contenu dynamique, Nginx peut transmettre des demandes à un serveur d'applications (tel que PHP-FPM) ou les proxy sur un serveur Apache. Cependant, Nginx ne gère pas le contenu dynamique localement comme Apache utilise son module mod_php.

Comment APACH gère-t-il le contenu statique et dynamique de différentes manières?

Apache peut fournir un contenu statique et dynamique. Pour le contenu statique, Apache utilise ses modules de base. Pour le contenu dynamique, Apache utilise des modules supplémentaires tels que MOD_PHP pour traiter les scripts PHP. Cependant, le modèle axé sur les processus d'Apache peut conduire à une grande quantité d'utilisation de la mémoire lorsqu'il s'agit de plusieurs connexions simultanées, ce qui le rend moins efficace que Nginx en termes de livraison de contenu statique.

Quel impact l'optimisation du serveur a-t-elle sur les performances du site Web?

L'optimisation du serveur peut améliorer considérablement les performances du site Web. Il peut réduire le temps de réponse du serveur, augmenter le nombre de connexions simultanées que le serveur peut gérer et réduire l'utilisation de la bande passante. Cela peut entraîner des temps de chargement de page plus rapides, une meilleure expérience utilisateur et une amélioration des classements SEO.

Comment choisir entre Apache et Nginx?

Choisir entre Apache et Nginx dépend de vos besoins spécifiques. Si vous avez besoin d'un serveur qui peut gérer efficacement beaucoup de connexions simultanées, ou si vous servez principalement du contenu statique, alors Nginx peut être un meilleur choix. Si vous avez besoin d'un serveur qui a une prise en charge solide pour le traitement de contenu dynamique, ou si vous comptez sur des fichiers .htaccess pour la configuration, Apache peut être plus approprié.

Quels sont les problèmes de performances courants avec Apache et Nginx?

Les problèmes de performances courants avec Apache incluent une utilisation élevée de la mémoire et des temps de réponse lents lors de la gestion de plusieurs connexions simultanées. Pour Nginx, les problèmes communs incluent une mauvaise configuration des processus et des connexions de travailleurs et le manque de capacités de traitement de contenu dynamique.

Comment surveiller les performances d'Apache et Nginx?

Vous pouvez utiliser une variété d'outils pour surveiller les performances d'Apache et de Nginx. Pour Apache, vous pouvez utiliser le module MOD_STATUS pour fournir des informations d'état du serveur. Pour Nginx, vous pouvez utiliser le module Stub_Status. De plus, vous pouvez utiliser des outils de surveillance tiers tels que New Relic, Datadog ou Nagios pour obtenir des métriques de performances et des alertes plus détaillées.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!