Apache modifie le nombre maximum de connexions simultanées

Apache fournit plusieurs modules MPM différents pour différents systèmes d'exploitation, tels que : mpm_beos, mpm_event, mpm_netware, mpmt_os2, mpm_prefork, mpm_winnt, mpm_worker. Si les conditions le permettent, nous pouvons compiler le module MPM spécifié dans notre propre Apache en fonction des besoins réels (le code source d'Apache est ouvert, permettant aux utilisateurs de le compiler eux-mêmes). Cependant, si l'on ne choisit pas lors de la compilation, Apache sélectionnera le module MPM correspondant en fonction des différents systèmes d'exploitation selon le tableau suivant. C'est également le module MPM recommandé par Apache pour les différentes plateformes.

(Tutoriel recommandé : Apache)

Module MPM par défaut sur différents systèmes d'exploitation

Description du module MPM du système d'exploitation

Windowsmpm_winnt n'a pas besoin d'être présenté :)

Unix/Linuxmpm_prefork n'a pas besoin d'être présenté :)

BeOSmpm_beos est un système d'exploitation multimédia développé par Be Company. La version officielle a cessé de se mettre à jour.

Netwarempm_netware est un système d'exploitation réseau lancé par NOVELL

OS/2mpmt_os2 est un système d'exploitation initialement développé conjointement par Microsoft et IBM, et est désormais développé uniquement par IBM (Microsoft a abandonné OS/2, passé au développement de Windows)

Le module mpm_event peut être considéré comme une variante du module mpm_worker, mais il est expérimental et son utilisation n'est généralement pas recommandée.

Bien sûr, Apache fournit également Apache terminé sur son site officiel qui a compilé les modules MPM correspondants selon différents systèmes d'exploitation. Vous pouvez cliquer ici pour accéder au site officiel d'Apache pour télécharger.

De plus, si nous voulons savoir quel type de module MPM est utilisé en interne dans un Apache, nous pouvons entrer dans le répertoire d'installation d'Apache bin en utilisant la ligne de commande, puis taper la commande httpd -l pour afficher le actuel Quel module MPM est utilisé en interne par Apache.

Utilisez la commande httpd -l pour afficher le module compilé

Étant donné que les systèmes d'exploitation tels que BeOS, NetWare et OS/2 ne sont pas courants dans le travail de développement normal, nous nous concentrons ici principalement sur Windows et Unix/Le module MPM sur le système d'exploitation Linux est expliqué. Sur les systèmes d'exploitation Windows et Unix/Linux, il existe trois modules MPM principaux : mpm_winnt, mpm_prefork et mpm_worker.

Module mpm_prefork

Le module mpm_prefork est principalement utilisé dans le serveur Apache sur la plateforme Unix/Linux. Sa principale méthode de fonctionnement est la suivante : au démarrage du serveur Apache, le module mpm_prefork pré-. créez plusieurs processus enfants (la valeur par défaut est 5), après avoir reçu la demande du client, le module mpm_prefork transfère ensuite la demande au sous-processus pour traitement, et chaque sous-processus ne peut être utilisé que pour traiter une seule demande en même temps . Si le nombre actuel de requêtes dépasse le nombre de sous-processus pré-créés, le module mpm_prefork créera de nouveaux sous-processus pour gérer les requêtes supplémentaires. Apache essaie toujours de garder certains processus enfants de rechange ou inactifs disponibles pour les demandes à venir. De cette façon, la demande du client n'a pas besoin d'attendre que le processus enfant soit généré après l'avoir reçu.

Comme dans le module mpm_prefork, chaque requête correspond à un processus enfant, elle occupe plus de ressources système que les deux autres modules. Cependant, l'avantage du module mpm_prefork est que chacun de ses sous-processus traitera indépendamment la requête unique correspondante, de sorte que si un problème survient avec l'une des requêtes, il n'affectera pas les autres requêtes. Dans le même temps, le module mpm_prefork peut être appliqué à des modules tiers qui ne sont pas thread-safe (tels que les versions non thread-safe de PHP) et est facile à déboguer sur les plates-formes qui ne prennent pas en charge le débogage des threads. De plus, le module mpm_prefork a également une stabilité plus élevée que le module mpm_worker.

Module mpm_worker

Le module mpm_worker est également principalement utilisé dans le serveur Apache sur la plateforme Unix/Linux. Il peut être considéré comme une version améliorée du module mpm_prefork. Le module mpm_worker fonctionne de la même manière que le module mpm_prefork. Cependant, lors du traitement de la même requête, un traitement basé sur un processus (tel que mpm_prefork) consomme plus de ressources système qu'un traitement basé sur un thread. Par conséquent, contrairement au module mpm_prefork, le module mpm_worker permettra à chaque processus enfant de créer un nombre fixe de threads de service et un thread d'écoute, et laissera chaque thread de service gérer la demande du client. Le thread d'écoute est utilisé pour surveiller les demandes d'accès et les envoyer. Transmis au thread de service pour traitement et réponse. Apache essaie toujours de maintenir un pool de threads de service de rechange ou inactifs. De cette façon, le client n'a pas besoin d'attendre qu'un nouveau thread ou processus soit établi avant de pouvoir le traiter.

Comparé au module mpm_prefork, le module mpm_worker peut réduire davantage la surcharge des ressources système. De plus, il utilise également plusieurs processus, et chaque processus possède plusieurs threads, ce qui ajoute un certain degré de stabilité par rapport à une méthode de traitement entièrement basée sur les threads.

module mpm_winnt

le module mpm_winnt est un module MPM optimisé et conçu spécifiquement pour les systèmes d'exploitation Windows. Il crée uniquement un processus enfant distinct et génère tour à tour plusieurs threads dans ce processus enfant pour gérer la demande.

Modifier la configuration du module MPM

Après avoir une certaine compréhension du module MPM d'Apache, nous pouvons modifier la configuration de connexion simultanée maximale d'Apache pour différents modules MPM.

1. Activer le fichier de configuration du module MPM

Il existe un fichier de configuration nommé httpd-mpm.conf dans le répertoire d'installation Apex/conf/extra. Ce fichier est principalement utilisé pour configurer le module MPM. Cependant, par défaut, le fichier de configuration du module MPM d'Apache n'est pas activé. Par conséquent, nous devons activer ce fichier de configuration dans le fichier httpd.conf comme suit :

# Gestion du pool de serveurs (spécifique à MPM) Inclure conf/extra/httpd-mpm.conf (supprimer le symbole de commentaire "# ")

2. Modifiez les configurations pertinentes dans le fichier de configuration du module MPM

Après avoir démarré le fichier de configuration du module MPM, nous pouvons utiliser un éditeur de texte pour ouvrir le fichier de configuration, nous comme vous pouvez voyez, il y a de nombreux nœuds de configuration dans ce fichier de configuration, comme le montre la figure ci-dessous :

La configuration correspondante ne prendra effet que lorsque Apache utilisera le module MPM correspondant

À ce stade, nous besoin Modifier la configuration des paramètres sous le nœud correspondant en fonction du module MPM actuellement utilisé par le serveur Apache. Tout d'abord, jetons un coup d'œil à la configuration par défaut sous le module mpm_winnt :

#Étant donné que le module mpm_winnt ne créera qu'un seul sous-processus, les paramètres d'un seul sous-processus ici sont équivalents aux paramètres des paramètres pour l'ensemble d'Apache. ThreadsPerChild 150# Paramètres recommandés : Petit site Web=1000 Site Web moyen=1000~2000 Grand site Web=2000~3500MaxRequestsPerChild 0# Paramètres recommandés : Petit=10000 Moyen ou grand=20000~100000

Les paramètres de configuration correspondants sont les suivants :

ThreadsPerChild

Le nombre maximum de threads simultanés par processus enfant.

MaxRequestsPerChild

Le nombre total de requêtes que chaque processus enfant est autorisé à traiter. Si le nombre cumulé de demandes traitées dépasse cette valeur, le sous-processus se terminera (et déterminera ensuite s'il faut créer un nouveau sous-processus si nécessaire. Définir cette valeur sur 0 signifie que le nombre total de demandes n'est pas limité (le sous-processus ne se terminera jamais). ).

Il est recommandé de définir ce paramètre sur une valeur non nulle, ce qui peut apporter les deux avantages suivants :

Cela peut empêcher d'éventuelles fuites de mémoire dans le programme de se poursuivre indéfiniment et de manquer de mémoire.

Donnez aux processus une durée de vie limitée, contribuant ainsi à réduire le nombre de processus actifs lorsque la charge du serveur est réduite.

Remarque : Parmi les paramètres ci-dessus liés au comptage du nombre de requêtes, pour les connexions KeepAlive, seule la première requête sera comptabilisée.

Ensuite, jetons un coup d'œil à la configuration par défaut sous le module mpm_perfork et le module mpm_worker :

#mpm_perfork module StartServers 5# Paramètres recommandés : Small = Par défaut Medium = 20~50 Large = 50 ~100MinSpareServers 5# Paramètres recommandés : cohérents avec StartServers MaxSpareServers 10# Paramètres recommandés : Small=20 Medium=30~80 Large=80~120 MaxClients 150# Paramètres recommandés : Small=500 Medium=500~1500 Large=1500~3000MaxRequestsPerChild 0# Paramètres recommandés : Petit = 10 000 Moyen ou Grand = 10 000 ~ 500 000 (De plus, le paramètre ServerLimit doit être défini en plus, ce qui correspond le mieux à la valeur de MaxClients.)

# StartServers:　　数量的服务器进程开始
# MinSpareServers:　　最小数量的服务器进程,保存备用
# MaxSpareServers:　　最大数量的服务器进程,保存备用
# MaxRequestWorkers:　　最大数量的服务器进程允许开始
# MaxConnectionsPerChild:　　最大连接数的一个服务器进程服务

prefork Contrôlez le processus pour initialement créer "StartServers" Une fois le processus enfant créé, créez un processus pour répondre aux besoins définis par MinSpareServers, attendez une seconde, continuez à en créer deux, attendez encore une seconde, continuez à en créer quatre... De cette façon, le nombre des processus créés augmentera de façon exponentielle, jusqu'à un maximum d'une seconde 32, jusqu'à ce que la valeur définie par MinSpareServers soit atteinte. Ce mode élimine le besoin de créer un nouveau processus lorsqu'une demande arrive, réduisant ainsi la surcharge du système et augmentant les performances. MaxSpareServers définit le nombre maximum de processus inactifs si le nombre de processus inactifs est supérieur à cette valeur, Apache supprimera automatiquement certains processus redondants. Ne définissez pas cette valeur trop grande, mais si la valeur est inférieure à MinSpareServers, Apache l'ajustera automatiquement à MinSpareServers+1. Si la charge du site est importante, envisagez d'augmenter simultanément MinSpareServers et MaxSpareServers.

MaxRequestsPerChild définit le nombre de requêtes que chaque processus enfant peut gérer. Chaque processus enfant sera automatiquement détruit après traitement des requêtes "MaxRequestsPerChild". 0 signifie infini, c'est-à-dire que le processus enfant n'est jamais détruit. Bien que le définir sur 0 par défaut permette à chaque processus enfant de traiter plus de requêtes, le définir sur une valeur non nulle présente également deux avantages importants :

1 Cela peut empêcher les fuites de mémoire accidentelles. 2. Lorsque la charge du serveur diminue, le nombre de processus enfants sera automatiquement réduit.

Par conséquent, cette valeur peut être ajustée en fonction de la charge sur le serveur.

L'ensemble de directives MaxRequestWorkers limitera le nombre de requêtes servies simultanément. Toute tentative de connexion dans la limite MaxRequestWorkers sera généralement mise en file d'attente, jusqu'à un certain nombre de directives basées sur ListenBacklog.

Dans les versions antérieures à Apache 2.3.13, les MaxRequestWorkers étaient appelés MaxClients.

(MaxClients est la plus importante de ces instructions. Elle définit les requêtes qu'Apache peut gérer en même temps. C'est le paramètre qui a le plus grand impact sur les performances d'Apache. Sa valeur par défaut de 150 est loin d'être Si le nombre total de requêtes a atteint cette valeur (peut être confirmé par ps -ef|grep http|wc -l), alors les requêtes suivantes seront mises en file d'attente jusqu'à ce qu'une requête traitée soit terminée. Cela signifie qu'il y a encore beaucoup de systèmes. Il reste des ressources mais l'accès HTTP n'est pas disponible. La principale raison d'être très lente Bien qu'en théorie, plus la valeur est grande, plus de requêtes peuvent être traitées, mais la limite par défaut d'Apache ne peut pas être supérieure à 256)

#mpm_worker module StartServers 2#Paramètres recommandés : Petit=Par défaut Moyen=3~5 Grand=5~10MaxClients 150#Paramètres recommandés : Petit=500 Moyen=500~1500 Grand=1500~3000MinSpareThreads 25#Paramètres recommandés : Petit= Moyen par défaut=50~100 Grand=100~200MaxSpareThreads 75#Paramètres recommandés : Petit=Moyen par défaut=80~160 Grand=200~400 ThreadsPerChild 25#Paramètres recommandés : Petit=Moyen par défaut=50~100 Grand=100~200MaxRequestsPerChild 0# Paramètres recommandés : Petit = 10 000 Moyen ou Grand = 10 000 ~ 50 000 (De plus, si MaxClients/ThreadsPerChild est supérieur à 16, vous devez définir en plus le paramètre ServerLimit. ServerLimit doit être supérieur ou égal à la valeur de MaxClients/ThreadsPerChild. )

configuration correspondante Les paramètres sont les suivants :

StartServers

Le nombre de processus enfants créés au démarrage d'Apache.

MinSpareServers

Nombre minimum de processus enfants en état d'inactivité.

Le processus enfant dit inactif fait référence à un processus enfant qui ne traite pas les demandes. Si le nombre actuel de processus enfants inactifs est inférieur à MinSpareServers, Apache générera de nouveaux processus enfants à un rythme maximum d'un par seconde. Le réglage de ce paramètre n'est nécessaire que sur les machines très sollicitées. Cette valeur ne doit pas être trop grande.

MaxSpareServers

Le nombre maximum de processus enfants inactifs.

Ce paramètre ne doit être ajusté que sur les machines très sollicitées. Cette valeur ne doit pas être trop grande. Si vous définissez la valeur de cette directive sur une valeur inférieure à MinSpareServers, Apache la modifiera automatiquement en MinSpareServers+1.

MaxClients

Le nombre maximum de requêtes autorisées pour les connexions simultanées.

Toute requête dépassant la limite MaxClients entrera dans la file d'attente jusqu'à ce que la valeur maximale de la limite de la directive ListenBacklog soit atteinte.

Pour MPM non threadé (c'est-à-dire mpm_prefork), MaxClients indique le nombre maximum de processus enfants pouvant être utilisés pour gérer les demandes des clients. La valeur par défaut est 256. Pour augmenter cette valeur, vous devez également augmenter ServerLimit.

Pour les MPM threadés ou mixtes (c'est-à-dire mpm_beos ou mpm_worker), MaxClients représente le nombre maximum de threads pouvant être utilisés pour traiter les requêtes des clients. La valeur par défaut du thread mpm_beos est 50. La valeur par défaut pour MPM mixte est 16 (ServerLimit) fois 25 (ThreadsPerChild). Par conséquent, lorsque vous augmentez MaxClients à plus de 16 processus à fournir, vous devez également augmenter la valeur de ServerLimit.

MinSpareThreads

Nombre minimum de threads en état d'inactivité.

Différents MPM gèrent cette commande différemment :

La valeur par défaut de mpm_worker est 75. Ce MPM surveillera le nombre de threads inactifs sur l'ensemble du serveur. Si le nombre total de threads inactifs sur le serveur est trop faible, le processus enfant générera de nouveaux threads inactifs. La valeur par défaut de mpm_netware est 10. Étant donné que ce MPM n'exécute qu'un seul processus enfant, ce MPM surveille également bien entendu le nombre de threads inactifs en fonction de l'ensemble du serveur. mpm_beos et mpmt_os2 fonctionnent de manière similaire à mpm_netware. La valeur par défaut de mpm_beos est 1 ; la valeur par défaut de mpmt_os2 est 5.

MaxSpareThreads

Le nombre maximum de threads inactifs.

Différents MPM gèrent cette commande différemment :

La valeur par défaut de mpm_worker est 250. Ce MPM surveillera le nombre de threads inactifs sur l'ensemble du serveur. Si le nombre total de threads inactifs sur le serveur est trop important, le processus enfant tuera les threads inactifs en excès. La valeur par défaut de mpm_netware est 100. Étant donné que ce MPM n'exécute qu'un seul processus enfant, ce MPM surveille également bien entendu le nombre de threads inactifs en fonction de l'ensemble du serveur. mpm_beos et mpmt_os2 fonctionnent de manière similaire à mpm_netware. La valeur par défaut de mpm_beos est 50 ; la valeur par défaut de mpmt_os2 est 10.

Remarque : ServerLimit représente le nombre maximum de processus qu'Apache permet de créer. Il convient de noter qu'Apache a une limite stricte interne de ServerLimit 20000 au moment de la compilation (ServerLimit 200000 pour le module mpm_prefork). Vous ne pouvez pas dépasser cette limite.

Soyez particulièrement prudent lorsque vous utilisez cette commande. Si ServerLimit est défini sur une valeur bien supérieure à celle réellement nécessaire, trop de mémoire partagée sera allouée. Si ServerLimit et MaxClients sont définis pour dépasser les capacités de traitement du système, Apache risque de ne pas démarrer ou le système peut devenir instable.

Remarque : lors de la configuration des paramètres pertinents, veuillez d'abord vous assurer que le serveur dispose de performances matérielles suffisantes (par exemple : CPU, mémoire, etc.). Si vous constatez que l'utilisation de la mémoire du serveur a augmenté à mesure que la durée d'exécution du serveur a augmenté depuis le démarrage, il peut s'agir d'une fuite de mémoire dans le programme. Veuillez ajuster la valeur du paramètre MaxRequestsPerChild à la baisse pour réduire l'impact de la fuite de mémoire, puis. procédez dès que possible. Découvrez où se situe le problème dans le programme.

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!