Comment limiter le nombre de processus php-cgi pour mod_fcgid ? Multitraitement Firefox : les tests continuent

Les processus php-cgi consomment de la mémoire, se multiplient de façon exponentielle et ne veulent pas mourir après l'expiration de la limite FcgidMaxRequestsPerProcess, après quoi php-cgi commence activement à tout vider dans le swap et le système commence à émettre "502 Mauvaise passerelle ".

À limiter le nombre de processus php-cgi fork, il ne suffit pas de définir FcgidMaxRequestsPerProcess, après quoi les processus doivent être tués, mais ils ne le font pas toujours volontairement.

La situation est douloureusement familière lorsque php-cgi traite ( enfant) rongeant la mémoire prolifèrent, mais vous ne pouvez pas les faire mourir - ils veulent vivre !

Il est possible de régler l'éternel déséquilibre entre ancêtres et enfants en limitant le nombre d'enfants php-cgi, leur durée de vie ( génocide) et contrôler l'activité de leur reproduction ( la contraception).

Limiter le nombre de processus php-cgi pour mod_fcgid

Les directives données ci-dessous jouent probablement le plus le rôle principal dans limiter le nombre de processus php-cgi et dans la plupart des cas les valeurs par défaut données ici sont préjudiciables pour les serveurs dont la RAM est inférieure à 5-10 Go :

• FcgidMaxProcessus 1000 - quantité maximale des processus qui peuvent être actifs en même temps ;
• FcgidMaxProcessesPerClass 100- le nombre maximum de processus dans une classe ( segment), c'est à dire. le nombre maximum de processus autorisés à apparaître via le même wrapper ( emballage - emballage);
• FcgidMinProcessesPerClass 3- le nombre minimum de processus dans une classe ( segment), c'est à dire. le nombre minimum de processus lancés via le même wrapper ( emballage - emballage), qui sera disponible une fois toutes les demandes terminées ;
• FcgidMaxRequestsPerProcess 0- FastCGI devrait "jouer la boîte" après avoir terminé ce nombre de requêtes.

Lequel numéro php-cgi processus sera le plus optimal ? Pour déterminer le nombre optimal de processus php-cgi, vous avez besoin de (pub) Inscrivez-vous sur notre site ! :)(/pub) (reg) prend en compte le volume total mémoire vive et la taille mémoire allouée pour PHP dans memory_limit ( php.ini), qui peut être absorbé par chacun des processus php-cgi lors de l'exécution d'un script PHP. Ainsi, par exemple, si nous avons 512 Mo, dont 150-200 sont alloués pour le système d'exploitation lui-même, un autre 50-100 pour le serveur de base de données, le MTA de messagerie, etc., et memory_limit = 64, alors dans ce cas notre 200- 250 Mo, nous pouvons exécuter 3-4 processus php-cgi simultanément sans trop de dégâts.(/reg)

Paramètres de temporisation du processus php-cgi

Avec la reproduction active des enfants php-cgi, mangeant de la RAM, ils peuvent vivre presque éternellement, et cela est semé de cataclysmes. Vous trouverez ci-dessous une liste de directives OGM pour aider à réduire durée de vie des processus php-cgi et libérer en temps voulu les ressources qu'ils occupent :

• FcgidIOTimeout 40- temps ( en sec.) pendant laquelle le module mod_fcgid tentera d'exécuter le script.
• FcgidProcessLifeTime 3600- si le processus existe plus longtemps que ce temps ( en secondes), alors il devra être marqué pour destruction lors de la prochaine analyse de processus, dont l'intervalle est défini dans la directive FcgidIdleScanInterval ;
• FcgidIdleTimeout 300- si le nombre de processus dépasse FcgidMinProcessesPerClass, alors le processus qui ne traite pas les requêtes pendant ce temps (en secondes), lors du prochain scan de processus, dont l'intervalle est défini dans la directive FcgidIdleScanInterval, sera marqué pour être tué ;
• FcgidIdleScanInterval 120- l'intervalle auquel le module mod_fcgid recherchera les processus ayant dépassé les limites FcgidIdleTimeout ou FcgidProcessLifeTime.
• FcgidBusyTimeout 300- si le processus est occupé à traiter les demandes pendant plus de cette durée ( en sec.), puis lors de la prochaine analyse, dont l'intervalle est défini dans FcgidBusyScanInterval, un tel processus sera marqué pour être tué ;
• FcgidBusyScanInterval 120- l'intervalle pendant lequel l'analyse et la recherche des processus occupés qui ont dépassé la limite FcgidBusyTimeout sont effectuées ;
• FcgidErrorScanInterval 3- intervalle ( en sec.), à travers lequel le module mod_fcgid tuera les processus en attente d'achèvement, incl. et ceux qui ont dépassé FcgidIdleTimeout ou FcgidProcessLifeTime. La mise à mort se fait en envoyant un signal SIGTERM au processus, et si le processus est toujours actif, il est tué par le signal SIGKILL.

Il faut tenir compte du fait qu'un processus dépassant FcgidIdleTimeout ou FcgidBusyTimeout peut vivre + plus de temps FcgidIdleScanInterval ou FcgidBusyScanInterval, à travers lequel il sera marqué pour destruction.

Il est préférable de définir ScanInterval avec une différence de plusieurs secondes, par exemple, si FcgidIdleScanInterval 120, puis FcgidBusyScanInterval 117 - c'est-à-dire afin que l'analyse des processus ne se produise pas en même temps.

Activité générant des processus php-cgi

Si rien de ce qui précède n'a aidé, ce qui est surprenant, vous pouvez toujours essayer de bricoler l'activité de génération des processus php-cgi ...

Outre les limites du nombre de requêtes, de processus php-cgi et de leur durée de vie, il existe également une activité de génération de processus enfants, qui peut être régulée par des directives telles que FcgidSpawnScore, FcgidTerminationScore, FcgidTimeScore et FcgidSpawnScoreUpLimit, le dont je pense avoir donné la traduction correcte de la part de la bourgeoisie ( les valeurs par défaut sont spécifiées( But) ne tombe pas en dessous de cette limite.

Si ma traduction de la description et la compréhension des paramètres ci-dessus sont correctes, alors pour réduire l'activité de génération des processus php-cgi, vous devez réduire la valeur de la directive FcgidSpawnScoreUpLimit ou augmenter les valeurs FcgidSpawnScore et FcgidTerminationScore.

Résultats

J'espère avoir répertorié et mâché en détail la plupart des directives mod_fcgid qui vous aideront limiter le nombre de php-cgi et leur durée de vie ainsi qu'une moindre consommation de ressources. Le complet configuration mod_fcgid pour un serveur fonctionnant correctement avec un processeur 2500 MHz et 512 Mo de RAM :

Oleg Golovski

Généralement, si vous le pouvez ne pas soulever Apache, ne faites pas cela. Déterminez si lighttpd ou thttpd peut effectuer les tâches dont vous avez besoin. Ces serveurs Web peuvent être très utiles dans les situations où les ressources système ne sont pas suffisantes pour tout le monde, mais devraient fonctionner. Je le répète encore une fois : nous parlons de ces situations où la fonctionnalité de ces produits sera suffisante pour effectuer les tâches assignées (en passant, lighttpd sait travailler avec PHP). Dans les situations où aucun Apache eh bien, ce n'est tout simplement pas suffisant, vous pouvez toujours libérer beaucoup de ressources système en redirigeant les requêtes vers du contenu statique (JavaScript, graphiques) à partir de Apacheà un serveur HTTP léger. Le plus grand défi Apache c'est son grand appétit pour la RAM. Dans cet article, je vais examiner des méthodes pour accélérer votre travail et réduire la quantité de mémoire qu'il occupe :

Charger moins de modules

La première étape consiste à se débarrasser du chargement de modules inutiles. Passez en revue les fichiers de configuration et déterminez les modules que vous avez chargés. Avez-vous besoin de tous les modules chargeables ? Trouvez ce qui n'est pas utilisé et désactivez nafig, cela vous fera économiser de la mémoire.

Gérer moins de demandes simultanées

Plus il y a de processus Apache autorisé à s'exécuter simultanément, plus il peut gérer de demandes simultanées. En augmentant ce nombre, vous augmentez ainsi la quantité de mémoire allouée pour Apache... En utilisant top, vous pouvez voir que chaque processus Apache prend très peu de mémoire car des bibliothèques partagées sont utilisées. DANS Debian 5 avec Apache 2 la configuration par défaut est la suivante :

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 20 MaxRequestsPerChild 0

Directif Serveurs de démarrage détermine le nombre de processus serveur démarrés initialement, immédiatement après son démarrage. Directives MinSpareServers et MaxSpareServers définir le nombre minimum et maximum de processus enfants « de rechange » Apache... De tels processus sont en attente de requêtes entrantes et ne sont pas déchargés, ce qui permet d'accélérer la réponse du serveur aux nouvelles requêtes. Directif Les clients de Max détermine le nombre maximum de requêtes simultanées que le serveur peut traiter simultanément. Lorsque le nombre de connexions simultanées dépasse ce nombre, de nouvelles connexions seront mises en file d'attente pour traitement. En effet, la directive Les clients de Max et définit le nombre maximum autorisé de processus enfants Apache fonctionnant simultanément. Directif MaxRequêtesParEnfant détermine le nombre de requêtes que le processus enfant doit traiter Apache avant de mettre fin à son existence. Si la valeur de cette directive est définie sur zéro, le processus n'expirera pas.

Pour son serveur domestique, avec les besoins correspondants, j'ai corrigé la configuration comme suit :

StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients 5 MaxRequestsPerChild 300

Bien sûr, la configuration ci-dessus est totalement inadaptée à une utilisation sur des serveurs très chargés, mais pour la maison, à mon avis, c'est la plus elle.

Circulation des processus

Comme vous pouvez le voir, j'ai changé la valeur de la directive MaxRequêtesParEnfant... En limitant ainsi la durée de vie des processus enfants par le nombre de requêtes traitées, vous pouvez éviter les fuites de mémoire accidentelles causées par des scripts tordus.

Utilisation pas trop longue de KeepAlives

Rester en vie est une méthode d'accompagnement connexion permanente entre client et serveur. Initialement Protocole HTTP a été conçu pour ne pas être orienté connexion persistante. C'est-à-dire que lorsqu'une page Web est envoyée à un client, toutes ses parties (images, cadres, JavaScript) sont transmises à l'aide de différentes connexions établies séparément. Avec l'avènement de Rester en vie, les navigateurs ont désormais la possibilité de demander une connexion persistante et, une fois celle-ci établie, de charger des données à l'aide d'un connexion établie... Cette méthode permet un gain de performances significatif. mais Apache Par défaut, il utilise un délai d'attente trop long avant de fermer la connexion, égal à 15 secondes. Cela signifie qu'après que tout le contenu a été fourni au client qui a demandé Rester en vie, le processus enfant attendra les demandes entrantes pendant 15 secondes supplémentaires. Un peu trop cependant. Il est préférable de réduire ce délai d'attente à 2-3 secondes.

KeepAliveTimeout 2

Réduction du délai d'attente

Alternativement, vous pouvez diminuer la valeur de la directive Temps libre, qui détermine le temps d'attente pour l'achèvement des demandes individuelles. Par défaut, sa valeur est 300 , peut-être que dans votre cas, il sera judicieux de diminuer/augmenter cette valeur. Personnellement, je l'ai laissé tel quel pour le moment.

Réduire l'intensité de l'exploitation forestière

Pour augmenter les performances du serveur, vous pouvez essayer de réduire l'intensité de la journalisation. des modules comme mod_rewrite, peut écrire dans le journal informations de débogage, et si vous n'en avez pas besoin, désactivez sa sortie.

Désactiver la résolution de nom d'hôte

À mon avis, il n'est pas nécessaire de faire la traduction inverse des adresses IP en noms d'hôtes. Si vous en avez vraiment besoin lors de l'analyse des journaux, vous pouvez les déterminer au stade de l'analyse, et non pendant le fonctionnement du serveur. La directive est responsable de la résolution des noms d'hôtes Recherches de nom d'hôte qui est en fait la valeur par défaut et est défini sur Désactivé cependant, cochez cette case si vous pensez vraiment que vous devez désactiver la transformation.

Recherches de nom d'hôte désactivées

Désactiver l'utilisation de .htaccess

La gestion des fichiers .htaccess effectué Apache chaque fois que vous demandez des données. Non seulement que Apache devez télécharger ce fichier, il faut donc encore beaucoup de temps et de ressources pour le traiter. Jetez un œil à votre serveur Web et reconsidérez la nécessité d'utiliser des fichiers .htaccess... Si tu as besoin divers réglages pour des répertoires différents, peut-être sera-t-il vraiment possible de les déplacer dans le fichier de configuration du serveur principal ? Et désactiver le traitement .htaccess c'est possible par une directive dans la configuration du serveur.

Il y a environ quatre mois Mozilla a démarré premiers essais d'architecture multiprocessus. Dans Firefox 48, une petite partie des utilisateurs, puis l'échantillon de test a été augmenté d'une fois et demie. Selon Mozilla dans son blog officiel, presque tous les utilisateurs de Firefox sans extensions installées faisaient partie des testeurs.

Les résultats de l'expérience se sont avérés très bons. Le temps de réponse du navigateur a diminué de 400 % et les améliorations de la vitesse de chargement des pages ont été de 700 %.

Il ne reste plus beaucoup de temps avant la fin des tests, lorsque le multitraitement deviendra une fonctionnalité standard intégrée de Firefox, de sorte que Fire Fox rattrapera (ou dépassera) la stabilité, la sécurité et la vitesse Chrome fonctionne, Edge, Safari et Internet Explorer qui utilisent depuis longtemps une architecture multiprocesseur.

Le multitraitement signifie que Firefox est capable de répartir les tâches sur plusieurs processus. En pratique, dans le navigateur, cela revient à isoler le moteur de rendu des interface utilisateur navigateur. Ainsi, le problème de rendu de la page Web n'entraîne pas le blocage de l'ensemble du navigateur, ce qui augmente la stabilité globale du travail. Si un processus de rendu isolé distinct est en cours d'exécution pour chaque onglet, le problème de gel sera limité à un seul onglet. De plus, l'isolement du rendu dans un bac à sable séparé augmente la sécurité du travail : il est plus difficile d'exploiter les vulnérabilités du moteur de rendu.

Chrome et d'autres utilisent le multitraitement depuis des années. Dans Chrome, il est présent depuis la toute première version, sortie en 2008. C'était, en un sens, une percée technologique. Il est intéressant de noter que pour créer ce tout premier Versions chromées Google a invité plusieurs développeurs Firefox dans l'équipe, et ils n'ont pas déçu.

Mais pour Mozilla lui-même, l'affaire a un peu calé. Le développement d'une architecture multi-processus, nom de code Electrolyse (e10s), a commencé en 2009, mais entre 2011 et 2013, il a été arrêté "en raison d'un changement de priorités".

Avec un rapport de compatibilité des modules complémentaires séparé, vous pouvez vérifier si vos modules complémentaires sont compatibles avec le multitraitement de Firefox.

Il reste maintenant quelques étapes finales. Il est nécessaire de fournir travail normal navigateur dans Firefox construit avec des extensions qui ne prennent pas encore en charge le multitraitement. Selon le plan, Firefox 51 prévoit de fonctionner avec des extensions qui ne sont pas explicitement marquées comme incompatibles avec le multitraitement.

De plus, Mozilla affinera l'architecture elle-même. En plus de séparer le moteur de rendu en un processus distinct, la prise en charge de plusieurs processus de contenu doit être implémentée. Dans ce cas, l'augmentation des performances sera maximale et les risques de stabilité du navigateur liés au gel des onglets individuels seront minimisés.

Tout d'abord, le deuxième processus de contenu a été mis en œuvre sur la branche Nightly. Maintenant, les développeurs vérifient le nombre de processus distincts que l'électrolyse peut supporter et détectent les bogues.

Le deuxième grand défi consiste à implémenter un bac à sable de sécurité avec des processus enfants restreints. Dans Firefox 50, le bac à sable a été implémenté pour la première fois dans une version Windows. Il s'agit encore de la première version expérimentale, mal protégée, préviennent les développeurs. Dans ce qui suit Versions de Firefox le bac à sable sera ajouté aux versions Mac et Linux.

Malgré plusieurs années de retard, Firefox introduit enfin le multitraitement. Et c'est une excellente nouvelle pour tous les utilisateurs de ce merveilleux navigateur. Mieux vaut tard que jamais. Et il vaut mieux tout faire correctement et ne pas se précipiter. Les premiers tests ont montré que l'électrolyse offrait des améliorations significatives en termes de performances, de stabilité et de sécurité.

S'applique à : System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

Surveillance un modèle vous permet de savoir si un processus particulier est en cours d'exécution sur votre ordinateur. En utilisant ce modèle, vous pouvez implémenter deux scénarios de base différents : un processus peut être requis pour s'exécuter pour une application spécifique et une alerte s'il ne fonctionne pas, ou une alerte peut être requise si un processus indésirable est en cours d'exécution. En plus de surveiller si une application est en cours d'exécution, vous pouvez collecter des données sur les performances du processeur et la mémoire utilisée par un processus.

Scénarios

Utilisation surveillance modèle dans divers scénarios où vous souhaitez surveiller le processus en cours d'exécution d'un ordinateur contrôlé par un agent sous Contrôle des fenêtres... Les applications peuvent surveiller les processus suivants.

Processus critique

Un processus qui doit être lancé à tout moment. Utilisation surveillance modèle pour s'assurer que ce processus est en cours d'exécution sur les ordinateurs où il est installé et pour utiliser surveillance un modèle pour mesurer ses performances.

Processus indésirable

Un processus qui ne devrait pas être en cours d'exécution. Ce processus peut être un processus étranger connu qui peut causer des dommages, ou il peut s'agir d'un processus qui démarre automatiquement lorsqu'une erreur se produit dans l'application. Surveillance template peut être surveillé pour ce processus et envoyé une alerte s'il s'exécute.

Processus de longue durée.

Un processus qui prend peu de temps. Si un processus s'exécute depuis trop longtemps, cela peut indiquer un problème. Surveillance Le modèle peut être surveillé tout au long du temps, ce processus est exécuté et une alerte est envoyée si le temps d'exécution dépasse une certaine durée.

Surveillance effectuée par le modèle de surveillance de processus

Selon la sélection effectuée dans l'assistant de surveillance, la surveillance effectuée par les moniteurs et les règles générés peut inclure l'un des paramètres suivants.

Affichage des données de surveillance

Toutes les données collectées surveillance le modèle est disponible en état du processus la vue est dans Suivi des processus et Services Windows Dossiers. Dans cette vue, l'objet est affiché pour chaque agent du groupe sélectionné. Même si l'agent ne surveille pas le processus, il est répertorié et le moniteur reflète l'état du processus qui n'est pas en cours d'exécution.

Vous pouvez afficher l'état des moniteurs de processus individuels en ouvrant l'analyseur d'intégrité Operations Manager pour un objet de processus. Vous pouvez afficher les données de performances en ouvrant la vue des performances d'un objet de processus.

Les mêmes objets de processus qui sont répertoriés dans état du processus les vues sont incluses dans l'analyseur de santé de l'ordinateur hébergeant le processus. L'état de santé des moniteurs est un processus qui augmente la santé de l'ordinateur.

Options de l'assistant

Au démarrage surveillance template, vous devez définir les valeurs des paramètres dans les tableaux suivants. Chaque tableau représente page séparée Maître.

Les propriétés générales

Paramètres communs page de l'assistant.

Processus de suivi

Les options suivantes sont disponibles sur processus à suivre page de l'assistant.

Processus en cours d'exécution

Les options suivantes sont disponibles sur processus en cours d'exécution page de l'assistant.

Données de performance

Les options suivantes sont disponibles sur données de performance page de l'assistant.

Fonctions de surveillance supplémentaires

En plus d'effectuer la surveillance spécifiée surveillance le modèle crée une classe ciblée qui peut être utilisée pour des moniteurs et des processus de travail supplémentaires. Le moniteur ou la règle utilisant cette classe comme cible s'exécutera sur n'importe quel ordinateur géré par agent dans le groupe spécifié dans le modèle. S'il génère des événements Windows qui indiquent une erreur, par exemple, vous pouvez créer un moniteur ou une règle qui identifie un événement spécifique et l'utilise comme objet cible classe du processus.

17 déc 2010

Ici, vous pouvez télécharger gratuitement.
Ce matériel est fourni par le site à titre informatif seulement. L'administration n'est pas responsable de son contenu.

Dans cet article, je vais décrire différences fondamentales Apache et Nginx, architecture frontend-backend, installer Apache en tant que backend et Nginx en tant que frontend. Et je vais aussi décrire une technologie qui permet d'accélérer le travail d'un serveur web : gzip_static + yuicompressor.

Nginx- le serveur est léger ; il démarre le nombre de processus spécifié (généralement le nombre de processus = le nombre de cœurs), et chaque processus de la boucle accepte les nouvelles connexions, traite les actuelles. Ce modèle permet de servir un grand nombre de clients avec de faibles coûts de ressources. Cependant, avec un tel modèle, il est impossible d'effectuer des opérations à long terme lors du traitement d'une requête (par exemple, mod_php), car cela bloquera essentiellement le serveur. A chaque cycle du processus, deux opérations sont essentiellement effectuées : lire un bloc de données quelque part, l'écrire quelque part. De quelque part et quelque part - il s'agit d'une connexion client, d'une connexion à un autre serveur Web ou à un processus FastCGI, système de fichiers, un tampon en mémoire. Le modèle de travail est configuré avec deux paramètres principaux :
worker_processes est le nombre de processus à démarrer. Généralement défini égal au nombre de cœurs de processeur.
connexions_travailleurs - nombre maximal connexions traitées par un seul processus. Dépend directement du nombre maximum de descripteurs de fichiers ouverts sur le système (1024 par défaut sous Linux).

Apache- le serveur est lourd (à noter que, si on le souhaite, il peut être suffisamment allégé, mais cela ne changera pas son architecture) ; il a deux principaux modèles de travail - prefork et worker.
Lors de l'utilisation du modèle prefork, Apache crée un nouveau processus pour gérer chaque requête, et ce processus fait tout le travail : accepte la requête, génère du contenu, le donne à l'utilisateur. Ce modèle est configuré avec les paramètres suivants :

MinSpareServers - le nombre minimum de processus inactifs. Cela est nécessaire pour commencer à le traiter plus rapidement lorsqu'une demande arrive. Le serveur Web lancera des processus supplémentaires pour fournir le numéro spécifié.
MaxSpareServers - Le nombre maximum de processus inactifs. Ceci est nécessaire pour ne pas occuper de mémoire supplémentaire. Le serveur Web tuera les processus inutiles.
MaxClients - le nombre maximum de clients servis simultanément. Le serveur Web ne démarrera pas plus que le nombre de processus spécifié.
MaxRequestsPerChild - le nombre maximum de requêtes que le processus traitera, après quoi le serveur Web le tuera. Encore une fois, pour économiser de la mémoire. la mémoire dans les processus va progressivement "s'écouler".

Ce modèle était le seul supporté par Apache 1.3. Il est stable, ne nécessite pas de multithreading depuis le système, mais il consomme beaucoup de ressources et perd un peu en vitesse au profit du modèle worker.
Lors de l'utilisation du modèle de travail, Apache crée plusieurs processus, avec plusieurs threads dans chacun. De plus, chaque requête est entièrement traitée dans un thread séparé. Légèrement moins stable que la prefork, car le plantage d'un thread peut planter l'ensemble du processus, mais il s'exécute un peu plus rapidement et utilise moins de ressources. Ce modèle est configuré avec les paramètres suivants :

StartServers - définit le nombre de processus à démarrer lorsque le serveur Web démarre.
MinSpareThreads - Le nombre minimum de threads inactifs dans chaque processus.
MaxSpareThreads - Le nombre maximum de threads inactifs dans chaque processus.
ThreadsPerChild - définit le nombre de threads que chaque processus démarre lorsque le processus démarre.
MaxClients - le nombre maximum de clients servis simultanément. Dans ce cas, précise nombre total threads dans tous les processus.
MaxRequestsPerChild - le nombre maximum de requêtes que le processus traitera, après quoi le serveur Web le tuera.

Back-end front-end

Le principal problème d'Apache est qu'un processus distinct est alloué pour chaque requête (au moins un thread), qui est également bloqué avec divers modules et consomme beaucoup de ressources. De plus, ce processus se bloquera en mémoire jusqu'à ce qu'il ait servi tout le contenu au client. Si le client dispose d'un canal étroit et que le contenu est suffisamment volumineux, cela peut prendre beaucoup de temps. Par exemple, le serveur va générer du contenu en 0,1 seconde, et il sera remis au client pendant 10 secondes, tout ce temps en prenant des ressources système.
Une architecture frontend-backend est utilisée pour résoudre ce problème. Son essence est que la requête d'un client arrive à un serveur léger, avec une architecture comme Nginx (frontend), qui redirige (proxy) la requête vers un serveur lourd (backend). Le backend génère du contenu, le donne très rapidement au frontend et libère des ressources système. Le front-end met le résultat du travail du backend dans son buffer et peut le donner (le résultat) au client pendant longtemps et de manière persistante, tout en consommant beaucoup moins de ressources que le backend. De plus, le frontend peut traiter indépendamment les demandes de fichiers statiques (css, js, images, etc.), contrôler l'accès, vérifier l'autorisation, etc.

Configuration du bundle Nginx (frontend) + Apache (backend)

On suppose que vous avez déjà installé Nginx et Apache. Vous devez configurer les serveurs pour qu'ils écoutent sur des ports différents. De plus, si les deux serveurs sont installés sur la même machine, il est préférable de bloquer le backend uniquement sur l'interface loopback (127.0.0.1). Dans Nginx, cela est configuré avec la directive listen :

Dans Apache, cela est configuré avec la directive Listen :

Écouter 127.0.0.1:81

Ensuite, vous devez dire à Nginx de transmettre les requêtes par proxy au backend. Ceci est fait avec la directive proxy_pass 127.0.0.1:81 ;. Tout cela est une configuration minimale. Cependant, nous avons dit plus haut qu'il est préférable de demander à Nginx de servir des fichiers statiques. Disons que nous avons un site PHP typique. Ensuite, nous devons uniquement transmettre par proxy les requêtes aux fichiers .php à Apache, en traitant tout le reste sur Nginx (si votre site utilise mod_rewrite, vous pouvez également effectuer des réécritures sur Nginx et simplement supprimer les fichiers .htaccess). Il est également nécessaire de prendre en compte le fait que la demande du client vient à Nginx et que la demande à Apache est faite par Nginx, il n'y aura donc pas d'en-tête Host https, et Apache définira l'adresse du client (REMOTE_ADDR) comme 127.0.0.1. L'en-tête Host est facile à remplacer, mais Apache détermine lui-même REMOTE_ADDR. Ce problème est résolu en utilisant mod_rpaf pour Apache. Cela fonctionne comme suit : Nginx connaît l'IP du client et ajoute un certain en-tête https (par exemple, X-Real-IP), dans lequel il attribue cette IP. mod_rpaf obtient cet en-tête et écrit son contenu dans la variable Apache REMOTE_ADDR. Ainsi, les scripts php exécutés par Apache verront la véritable IP du client.
Maintenant, la configuration va devenir plus compliquée. Tout d'abord, assurez-vous que le même hôte virtuel existe à la fois dans Nginx et Apache, avec la même racine. Exemple pour Nginx :

serveur (
écouter 80 ;
site nom_serveur ;
racine/var/www/site/;
}

Exemple pour Apache :

Site de nom de serveur

Maintenant, nous définissons les paramètres pour le schéma ci-dessus :
Nginx :
serveur (
écouter 80 ;
site nom_serveur ;
lieu / (
racine/var/www/site/;
index index.php;
}
emplacement ~ \ .php ($ | \ /) (
proxy_pass https://127.0.0.1:81;
proxy_set_header X-Real-IP $ remote_addr;
proxy_set_header Hôte $ hôte ;
}
}

# paramètres mod_rpaf
RPA Activé
RPAFproxy_ips 127.0.0.1
RPAFheader X-Real-IP

DocumentRoot "/var/www/site/"
Site de nom de serveur

L'expression régulière \ .php ($ | \ /) décrit deux situations : une requête à * .php et une requête à * .php / foo / bar. La deuxième option est requise pour que de nombreux CMS..com / index.php fonctionnent (puisque nous avons défini un fichier d'index) et sera également proxy pour Apache.

Accélérer : gzip_static + yuicompressor

Gzip sur le Web, c'est bien. Fichiers texte sont parfaitement compressés, le trafic est économisé et le contenu est livré à l'utilisateur plus rapidement. Nginx peut compresser à la volée, il n'y a donc pas de problème. Cependant, la compression d'un fichier prend un certain temps, y compris le temps CPU. C'est là que la directive Nginx gzip_static vient à la rescousse. L'essence de son travail est la suivante : si, lors de la demande d'un fichier, Nginx trouve un fichier avec le même nom et une extension supplémentaire ".gz", par exemple, style.css et style.css.gz, alors au lieu de compresser style.css, Nginx lira à partir du disque déjà compressé style.css.gz et le donnera comme compressé style.css.
Les paramètres Nginx ressembleront à ceci :

https (
...
gzip_static activé ;
gzip activé ;
gzip_comp_level 9 ;
application gzip_types / texte x-javascript / css;
...

Super, nous allons générer un fichier .gz une fois pour que Nginx le rende plusieurs fois. De plus, nous compresserons css et js à l'aide de YUI Compressor. Cet utilitaire minimise autant que possible les fichiers css et js, en supprimant les espaces, en abrégeant les noms, etc.
Et vous pouvez forcer tout cela à être compressé automatiquement, et même à mettre à jour automatiquement, en utilisant cron et un petit script. Ajoutez la commande suivante à cron pour qu'elle s'exécute une fois par jour :

/usr/bin/find/var/www -mmin 1500 -iname "* .js" -ou -iname "* .css" | xargs -i -n 1 -P 2 packfile.sh

dans le paramètre -P 2, précisez le nombre de cœurs de votre processeur, n'oubliez pas d'écrire le chemin complet vers packfile.sh et changez /var/www dans votre répertoire web.
Ajoutez au fichier packfile.sh.