{"id":17358,"date":"2026-02-05T11:52:30","date_gmt":"2026-02-05T10:52:30","guid":{"rendered":"https:\/\/webhosting.de\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/"},"modified":"2026-02-05T11:52:30","modified_gmt":"2026-02-05T10:52:30","slug":"wordpress-php-fpm-enfants-bloquer-optimisation-tuning-serverperf","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/wordpress-php-fpm-children-blockieren-optimierungstuning-serverperf\/","title":{"rendered":"WordPress PHP-FPM Children : des valeurs erron\u00e9es bloquent les pages"},"content":{"rendered":"<p><strong>PHP-FPM Enfants<\/strong> d\u00e9cident dans WordPress si les demandes sont fluides ou si elles restent bloqu\u00e9es dans la file d'attente. Je montre comment de fausses <strong>pm.max_children<\/strong>-Les valeurs bloquent les pages, mangent la RAM et comment calculer des valeurs propres.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Avant d'aller plus loin, je vais r\u00e9sumer bri\u00e8vement les messages cl\u00e9s :<\/p>\n<ul>\n  <li><strong>pm.max_children<\/strong> d\u00e9termine le nombre de requ\u00eates PHP simultan\u00e9es.<\/li>\n  <li><strong>Trop peu<\/strong> Children g\u00e9n\u00e8re des files d'attente, 502\/504 et un TTFB \u00e9lev\u00e9.<\/li>\n  <li><strong>Trop<\/strong> entra\u00eene des goulots d'\u00e9tranglement de RAM, des swap et des OOM-kills.<\/li>\n  <li><strong>Formule<\/strong>: RAM PHP disponible \/ taille du processus \u00d7 0,7-0,8.<\/li>\n  <li><strong>It\u00e9ratif<\/strong> Le tuning avec monitoring fournit la meilleure performance \u00e0 long terme.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-serverproblem-7193.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pourquoi les faux PHP-FPM Children bloquent-ils les pages ?<\/h2>\n\n<p>Chaque requ\u00eate dynamique de WordPress n\u00e9cessite un <strong>Travailleur<\/strong>, Et c'est pr\u00e9cis\u00e9ment ces processus que le pool contr\u00f4le via pm.max_children. Si je fixe une valeur trop basse, les demandes s'accumulent dans une file d'attente et les <strong>TTFB<\/strong> augmente sensiblement. Si je fixe une valeur trop \u00e9lev\u00e9e, chaque processus enfant utilise de la RAM suppl\u00e9mentaire et le serveur passe en swap. Dans le swap, tout ralentit jusqu'\u00e0 ce qu'Apache ou Nginx signale 502\/504 ou que le tueur d'OOM mette fin aux processus. Un d\u00e9bit sain n'est obtenu que lorsque le nombre d'enfants correspond au budget RAM r\u00e9el et \u00e0 la charge du projet.<\/p>\n\n<h2>La formule pour pm.max_children dans la pratique<\/h2>\n\n<p>Je commence avec une formule simple : la RAM disponible pour PHP divis\u00e9e par la taille moyenne d'un processus enfant, multipli\u00e9e par un <strong>Facteur de s\u00e9curit\u00e9<\/strong> Je d\u00e9termine la RAM par processus avec ps et la colonne RSS ; pour les piles WordPress typiques, 50-250 Mo sont souvent corrects. Sur un serveur de 4 Go, je r\u00e9serve de la m\u00e9moire pour Linux, la base de donn\u00e9es et les services de cache, de sorte qu'environ 1,5 \u00e0 2 Go sont consacr\u00e9s \u00e0 la gestion de la m\u00e9moire. <strong>PHP<\/strong> resteront \u00e0 l'\u00e9cran. Par exemple, si la moyenne du processus est de 100 Mo, 2.000 \/ 100 \u00d7 0,75 = 15 Children. Ce chiffre sert de point de d\u00e9part, que j'affine en fonction du profil de charge, de la mise en cache et du m\u00e9lange de plug-ins.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_fpm_meeting_4287.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valeurs de d\u00e9part pour les configurations typiques de WordPress<\/h2>\n\n<p>Pour les petits blogs avec 2 Go de RAM, 8 enfants, pm = dynamic et un pm.max_requests d'environ <strong>800<\/strong>. Pour les projets moyens avec 4 Go de RAM, je d\u00e9finis 12 enfants, start_servers 4, min_spare_servers 4. Les grandes boutiques \u00e0 partir de 8 Go de RAM b\u00e9n\u00e9ficient de 21 \u00e0 40 enfants ; en cas de charge \u00e9lev\u00e9e permanente, pm = static peut assurer un d\u00e9bit constant. Je v\u00e9rifie ensuite le rapport entre l'utilisation du CPU, l'utilisation de la RAM et les temps de r\u00e9ponse afin de proc\u00e9der \u00e0 un ajustement fin. Pour ceux qui souhaitent aller plus loin, vous trouverez des informations de fond sous <a href=\"https:\/\/webhosting.de\/fr\/wordpress-php-fpm-parametres-optimaux-performance-serverboost\/\">Param\u00e8tres PHP-FPM optimaux<\/a>.<\/p>\n\n<h2>Mesurer les processus : comment d\u00e9terminer les besoins en RAM<\/h2>\n\n<p>Je d\u00e9termine d'abord la taille r\u00e9elle des processus avant de fixer des valeurs, car les boules de cristal ne sont d'aucune aide et co\u00fbtent cher. <strong>Performance<\/strong>. La commande ps -ylC php-fpm -sort:rss fournit les tailles RSS que j'observe sur quelques minutes. Lors des mises \u00e0 jour ou des cronjobs, les processus prennent souvent de l'ampleur, c'est pourquoi je tiens compte des pics dans le calcul. En outre, je v\u00e9rifie les r\u00e9serves de RAM et la part de swap avec htop et free -h. Avec ces donn\u00e9es, je d\u00e9termine une moyenne robuste et je choisis le facteur de s\u00e9curit\u00e9 de mani\u00e8re conservatrice.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-phpfpm-blockiert-9327.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aper\u00e7u des param\u00e8tres importants<\/h2>\n\n<p>En plus de pm.max_children, d'autres options de pool d\u00e9terminent la propret\u00e9 avec laquelle WordPress traite les requ\u00eates et sa capacit\u00e9 \u00e0 lib\u00e9rer de la m\u00e9moire, ce qui peut avoir un impact sensible sur l'efficacit\u00e9 du syst\u00e8me. <strong>Stabilit\u00e9<\/strong> pm r\u00e8gle le mode : dynamic adapte le nombre de processus \u00e0 la charge, static maintient un nombre fixe. pm.max_requests emp\u00eache le memory-bloat en red\u00e9marrant les processus apr\u00e8s X requ\u00eates. request_terminate_timeout prot\u00e8ge contre les accrochages dus \u00e0 des scripts d\u00e9fectueux ou lents. Avec cet ensemble, je couvre 90% des cas pratiques r\u00e9els.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Fonction<\/th>\n      <th>Recommandation WordPress<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm<\/td>\n      <td>Mode de contr\u00f4le des processus<\/td>\n      <td>dynamic pour une charge variable ; static pour un trafic \u00e9lev\u00e9 permanent<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_children<\/td>\n      <td>Nombre maximal de travailleurs simultan\u00e9s<\/td>\n      <td>RAM PHP disponible \/ taille du processus \u00d7 0,75<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_requests<\/td>\n      <td>Recyclage des processus<\/td>\n      <td>300-1.000 ; plut\u00f4t plus bas pour WooCommerce<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>Abandon des requ\u00eates de longue dur\u00e9e<\/td>\n      <td>60-120 secondes contre les accrocs<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Dynamic, ondemand ou static - quel mode convient ?<\/h2>\n<p>Je choisis le mode adapt\u00e9 au profil de charge : <strong>dynamique<\/strong> est ma valeur par d\u00e9faut, car elle permet d'adapter de mani\u00e8re flexible le nombre de processus actifs et d'\u00e9conomiser ainsi de la RAM lorsque l'activit\u00e9 est faible. <strong>static<\/strong> Je l'utilise lorsque la charge est constante et que j'ai besoin de garanties solides en mati\u00e8re de latence et de d\u00e9bit, par exemple pendant les campagnes ou les ventes. <strong>ondemand<\/strong> convient aux serveurs ayant de longues p\u00e9riodes d'inactivit\u00e9 : Les processus ne sont cr\u00e9\u00e9s qu'en cas de besoin et sont arr\u00eat\u00e9s apr\u00e8s une p\u00e9riode d'inactivit\u00e9. Le trade-off, ce sont les d\u00e9marrages \u00e0 froid ; la premi\u00e8re demande par nouveau processus semble plus lente. Pour ondemand, je mets <em>pm.process_idle_timeout<\/em> (par ex. 10-20s), pour les dynamiques, je garde <em>start_servers<\/em>, <em>min_spare_servers<\/em> et <em>max_spare_servers<\/em> \u00e9troite, afin que le pool \u00e9volue rapidement, mais ne \u201egonfle\u201c pas.<\/p>\n\n<h2>Exemple de configuration pour ta piscine<\/h2>\n\n<p>Sur Debian\/Ubuntu, le fichier de pool se trouve g\u00e9n\u00e9ralement dans \/etc\/php\/8.x\/fpm\/pool.d\/www.conf, ce qui me donne une id\u00e9e claire de ce qu'est un pool. <strong>Structure<\/strong> pour les adaptations. Je r\u00e8gle pm sur dynamic, je fixe une valeur r\u00e9aliste pour pm.max_children et je garde les serveurs de secours \u00e9troits. Je r\u00e8gle le recyclage sur 500 pour \u00e9viter les fuites et les mont\u00e9es de RAM. Apr\u00e8s chaque modification, je teste la charge et \u00e9limine les goulets d'\u00e9tranglement avant d'augmenter les valeurs. Pour en savoir plus sur les valeurs limites, consultez le site <a href=\"https:\/\/webhosting.de\/fr\/php-fpm-gestion-des-processus-pm-max-children-optimiser-core\/\">Optimiser pm.max_children<\/a>.<\/p>\n\n<pre><code>pm = dynamic\npm.max_children = 15\npm.start_servers = 4\npm.min_spare_servers = 4\npm.max_spare_servers = 8\npm.max_requests = 500\nrequest_terminate_timeout = 90s\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_phpfpm_techoffice_9271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Plusieurs pools, sockets et isolation propre<\/h2>\n<p>Dans le cas de plusieurs projets ou de r\u00f4les clairement s\u00e9par\u00e9s (frontend vs. admin\/REST), je mets en place <strong>piscines s\u00e9par\u00e9es<\/strong> avec son propre utilisateur et son propre socket. Ainsi, chaque pool limite lui-m\u00eame ses children et un fuyard ne bloque pas le reste. Sur un h\u00f4te, je pr\u00e9f\u00e8re <strong>Sockets Unix<\/strong> par rapport \u00e0 TCP (listen = \/run\/php\/site.sock) - moins de latence, moins d'overhead. J'utilise TCP entre Nginx\/Apache et PHP-FPM sur diff\u00e9rents h\u00f4tes\/conteneurs. Je mets <em>listen.owner<\/em>, <em>listen.group<\/em> et <em>listen.mode<\/em> et, si n\u00e9cessaire, j'ai lev\u00e9 <em>listen.backlog<\/em> afin d'\u00e9viter que les courts pics de charge ne se transforment en erreurs de connexion. Avec un pool d'administrateurs d\u00e9di\u00e9, je peux cr\u00e9er un pool plus \u00e9troit. <em>request_terminate_timeout<\/em> conduire et <em>pm.max_requests<\/em> sans pour autant freiner le pool de front-end \u00e0 forte mise en cache.<\/p>\n\n<h2>Reconna\u00eetre les sympt\u00f4mes et r\u00e9agir correctement<\/h2>\n\n<p>Si le journal d'erreurs indique r\u00e9guli\u00e8rement \u201eserver reached pm.max_children\u201c, le pool limite les <strong>Parall\u00e9lisme<\/strong> et j'augmente mod\u00e9r\u00e9ment. Si 502\/504 apparaissent alors que l'utilisation du swap est \u00e9lev\u00e9e, je r\u00e9initialise pm.max_children et j'abaisse pm.max_requests. Si le CPU augmente alors que l'utilisation de la RAM est faible, ce sont g\u00e9n\u00e9ralement les requ\u00eates ou la logique PHP qui bloquent ; j'optimise la base de donn\u00e9es et la mise en cache. Si les requ\u00eates restent bloqu\u00e9es, un request_terminate_timeout plus strict et une analyse des logs avec des timestamps aident. Je v\u00e9rifie les pics remarquables par rapport aux t\u00e2ches cron, aux index de recherche et aux actions d'administration.<\/p>\n\n<h2>Statut du FPM et Slowlog : un diagnostic pr\u00e9cis<\/h2>\n<p>J'active le <strong>Statut<\/strong> par pool (pm.status_path) et lire des indicateurs tels que <em>processus actifs<\/em>, <em>max children reached<\/em>, <em>listen queue<\/em> et <em>max listen queue<\/em> est d\u00e9sactiv\u00e9e. Une file d'attente de listes qui s'agrandit en permanence montre clairement qu'il y a trop peu d'enfants ou que les backends bloquent. En outre, je place <em>request_slowlog_timeout<\/em> (par ex. 3-5s) et un <em>slowlog<\/em>-chemin d'acc\u00e8s. Je vois ainsi des traces de pile de requ\u00eates qui tra\u00eenent - il s'agit souvent d'appels HTTP externes, de requ\u00eates WooCommerce complexes ou de manipulations d'images. Avec <em>catch_workers_output<\/em> les avertissements des travailleurs sont rassembl\u00e9s dans les logs. Sur la base de ces donn\u00e9es, je d\u00e9cide si davantage de parall\u00e9lisme est utile ou si je dois r\u00e9soudre des goulots d'\u00e9tranglement dans le code\/la base de donn\u00e9es.<\/p>\n\n<h2>Monitoring : 3-5 jours d'\u00e9valuation propre<\/h2>\n\n<p>Apr\u00e8s le r\u00e9glage, j'observe les pics de charge pendant plusieurs jours, car les pics de charge \u00e0 court terme peuvent \u00eatre tr\u00e8s importants. <strong>fluctuations<\/strong> se tromper. J'enregistre la RAM, le swap, 502\/504, TTFB et le nombre de processus actifs dans l'\u00e9tat FPM. En dessous de 80 % d'utilisation de la RAM sans swap et sans files d'attente, je suis dans le vrai. Si des goulots d'\u00e9tranglement apparaissent lors d'actions telles que le checkout, la recherche ou les importations, je modifie de mani\u00e8re cibl\u00e9e pm.max_children et pm.max_requests. Chaque \u00e9tape fait l'objet de petits ajustements et d'une nouvelle mesure.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress_phpfpm_bugfix_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>La facture m\u00e9moire en d\u00e9tail : RSS, PSS et m\u00e9moire partag\u00e9e<\/h2>\n<p>La taille du processus est perfide : <strong>RSS<\/strong> (Resident Set Size) contient \u00e9galement des segments partag\u00e9s comme OPcache et les biblioth\u00e8ques. C'est pourquoi je surestime rapidement la consommation de RAM si je calcule simplement \u201eRSS \u00d7 Children\u201c. Il vaut mieux utiliser la <strong>PSS<\/strong>-(Proportional Set Size), qui r\u00e9partit la m\u00e9moire partag\u00e9e de mani\u00e8re \u00e9quitable entre les processus - des outils comme smem aident ici. Le calcul comprend <strong>OPcache<\/strong> (par exemple 256 Mo + strings), <strong>APCu<\/strong> (par ex. 64-128 Mo) et le processus ma\u00eetre. Le PHP <em>memory_limit<\/em> n'est pas une moyenne, mais la limite sup\u00e9rieure par requ\u00eate ; des pics isol\u00e9s peuvent survenir, mais c'est la moyenne qui compte. Je pr\u00e9vois une m\u00e9moire tampon pour que les pics, les d\u00e9ploiements et les cronjobs ne d\u00e9clenchent pas imm\u00e9diatement de swap et je laisse <em>pm.max_requests<\/em> agir consciemment pour limiter le blocage de la m\u00e9moire.<\/p>\n\n<h2>R\u00e9duire la charge sp\u00e9cifique \u00e0 WordPress<\/h2>\n\n<p>Je r\u00e9duis d'abord la charge PHP avant d'augmenter encore Children, car un taux de r\u00e9ussite de cache plus rapide permet d'\u00e9conomiser des ressources r\u00e9elles. <strong>RAM<\/strong>. Les caches pleine page r\u00e9duisent drastiquement les requ\u00eates PHP, ce qui lib\u00e8re de la capacit\u00e9 pour le checkout, la recherche et l'admin. OPcache avec memory_consumption autour de 256 Mo acc\u00e9l\u00e8re le bytecode et d\u00e9charge le pool. Je maintiens la memory_limit PHP \u00e0 256M, afin que les plugins ne ralentissent pas le serveur. Pour plus d'informations sur les goulots d'\u00e9tranglement, voir le guide <a href=\"https:\/\/webhosting.de\/fr\/php-workers-hosting-goulot-detranglement-guide-balance\/\">PHP Worker comme goulot d'\u00e9tranglement<\/a>.<\/p>\n\n<h2>\u00c9quilibre entre les backends de la base de donn\u00e9es et du cache<\/h2>\n<p>Chaque travailleur PHP g\u00e9n\u00e8re potentiellement une <strong>Connexion \u00e0 la base de donn\u00e9es<\/strong>. Si j'augmente pm.max_children, la charge simultan\u00e9e de la base de donn\u00e9es augmente \u00e9galement. Je v\u00e9rifie donc MySQL\/MariaDB : <em>max_connections<\/em>, tampon (innodb_buffer_pool_size), et le planificateur de requ\u00eates. Redis\/Memcached doivent suivre en parall\u00e8le - <em>maxclients<\/em>, garder un \u0153il sur la limite de m\u00e9moire et les latences. Une instance WordPress avec 20 enfants actifs peut facilement saturer la base de donn\u00e9es si plusieurs requ\u00eates co\u00fbteuses sont ex\u00e9cut\u00e9es en parall\u00e8le. C'est pourquoi je tune la BD (index, requ\u00eates lentes) et je mise sur <strong>caches d'objets persistants<\/strong>, avant de lib\u00e9rer d'autres children. Cela me permet d'augmenter le d\u00e9bit sans \u00e9craser le backend.<\/p>\n\n<h2>WooCommerce, Cron et Admin : cas particuliers<\/h2>\n\n<p>Les boutiques g\u00e9n\u00e8rent davantage de requ\u00eates dynamiques simultan\u00e9es, c'est pourquoi j'ai utilis\u00e9 quelque chose pour les checkouts. <strong>air<\/strong> \u00e0 pm.max_children. En m\u00eame temps, j'abaisse plut\u00f4t pm.max_requests afin de couper la m\u00e9moire bloqu\u00e9e en permanence. Pour les importations et les t\u00e2ches cron, je pr\u00e9vois un budget suppl\u00e9mentaire ou j'ex\u00e9cute les t\u00e2ches en dehors des heures de pointe. La zone d'administration est souvent en pointe \u00e0 court terme ; la mise en cache prot\u00e8ge moins ici, donc un contr\u00f4le efficace du pool est important. En cas de signes de files d'attente, j'augmente par petites \u00e9tapes et j'observe les m\u00e9triques imm\u00e9diatement apr\u00e8s.<\/p>\n\n<h2>Conteneurs, quotas vCPU et pi\u00e8ges OOM<\/h2>\n<p>Dans les conteneurs et les VM, l'attention se porte sur le <strong>efficace<\/strong> limite de RAM (cgroups), pas \u00e0 l'h\u00f4te. Je calcule donc pm.max_children \u00e0 partir de la limite allou\u00e9e et non de \u201efree -h\u201c. Les OOM de conteneurs sont impitoyables - le noyau met fin aux processus de mani\u00e8re brutale. Les quotas CPU comptent \u00e9galement : Plus de children ne servent \u00e0 rien si 1 ou 2 vCPUs limitent le temps de calcul. En r\u00e8gle g\u00e9n\u00e9rale, pour les charges de travail WordPress \u00e0 forte composante IO, je m'adapte \u00e0 environ 2-4\u00d7 le nombre de vCPU ; au-del\u00e0, les changements de contexte augmentent, mais pas le d\u00e9bit r\u00e9el. Dans les environnements orchestr\u00e9s, je d\u00e9ploie les modifications de mani\u00e8re conservatrice, j'observe les red\u00e9marrages de pods et je maintiens les tests de lecture\/viabilit\u00e9 de mani\u00e8re \u00e0 ce que les courtes phases d'\u00e9chauffement de FPM ne soient pas consid\u00e9r\u00e9es comme des pannes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/wordpress-server-techniker-7483.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Des sources d'erreurs souvent n\u00e9glig\u00e9es<\/h2>\n\n<p>De nombreux probl\u00e8mes ne proviennent pas de la piscine, mais de <strong>Plugins<\/strong>, qui multiplient les requ\u00eates ou g\u00e9n\u00e8rent de longs processus. Les recherches index\u00e9es, les r\u00e8gles de crawler cass\u00e9es et les intervalles de heartbeat surr\u00e9alistes font grimper la charge. C'est pourquoi je v\u00e9rifie toujours en premier lieu les logs, le Query Monitor et les en-t\u00eates de cache. Si la charge n'appara\u00eet que sur certaines URL, j'interpr\u00e8te cela comme une indication de goulots d'\u00e9tranglement de plugins ou de mod\u00e8les. Ce n'est que lorsque ces probl\u00e8mes ont \u00e9t\u00e9 r\u00e9solus que je continue \u00e0 faire \u00e9voluer Children.<\/p>\n\n<h2>Comprendre les sessions, Admin-AJAX et les verrous<\/h2>\n<p>WordPress\/plugins fonctionne en partie avec <strong>Sessions<\/strong>. Les verrous de session bas\u00e9s sur des fichiers peuvent rendre les requ\u00eates s\u00e9rielles - une seule requ\u00eate lente bloque le reste du m\u00eame identifiant de session. Je limite l'utilisation des sessions et v\u00e9rifie que les rafales AJAX d'admin (wp-admin\/admin-ajax.php) ne sont pas inutilement activ\u00e9es. Le heartbeat doit \u00eatre limit\u00e9 de mani\u00e8re raisonnable, sinon il g\u00e9n\u00e8re une charge sans valeur ajout\u00e9e. Si des blocages ou de longs acc\u00e8s aux fichiers se produisent, un parall\u00e9lisme accru n'apporte pas de solution ; la mise en cache, des E\/S de stockage plus rapides ou un autre gestionnaire de session peuvent aider. Dans les logs, je reconnais de tels mod\u00e8les \u00e0 de nombreuses requ\u00eates similaires d\u00e9marrant simultan\u00e9ment et pr\u00e9sentant des dur\u00e9es d'ex\u00e9cution inhabituellement longues.<\/p>\n\n<h2>Vue d'ensemble des d\u00e9lais Nginx, Apache et FastCGI<\/h2>\n\n<p>Le serveur web impose lui aussi des limites que je dois harmoniser avec les valeurs FPM, sans quoi <strong>Tuning<\/strong>. Sous Nginx, je fais attention \u00e0 fastcgi_read_timeout et \u00e0 un nombre suffisant de processus de travail. Sous Apache, je v\u00e9rifie mpm_event, les param\u00e8tres de Keepalive et les d\u00e9lais d'attente du proxy. Si ces limites ne sont pas correctes, les utilisateurs signalent des d\u00e9lais d'attente alors que FPM a encore de la capacit\u00e9. Des budgets temporels uniformes permettent de maintenir la coh\u00e9rence du chemin entre le client et PHP.<\/p>\n\n<h2>Strat\u00e9gie de d\u00e9ploiement, tests et op\u00e9rations<\/h2>\n<p>Je d\u00e9ploie progressivement les modifications de pm.max_children et les teste sous charge r\u00e9elle. Un rechargement de FPM (graceful) reprend les configurations sans interruption de la connexion. Avant les sauts importants, je simule des pics (par exemple le d\u00e9marrage de la vente) et j'observe alors <em>listen queue<\/em>, CPU, RAM, 95e-99e percentile de latence et taux d'erreur. Je documente les hypoth\u00e8ses retenues afin que les membres ult\u00e9rieurs de l'\u00e9quipe comprennent pourquoi une valeur a \u00e9t\u00e9 choisie de cette mani\u00e8re. Je d\u00e9finis des alarmes : swap &gt; 0, \u201emax children reached\u201c dans le statut, augmentation de 502\/504, et latence de la BD. Ainsi, la plateforme reste stable m\u00eame des mois plus tard, lorsque le trafic et le mix de plugins changent.<\/p>\n\n<h2>En bref<\/h2>\n\n<p>Mauvaise mise en place <strong>PHP-FPM<\/strong>-Les enfants ralentissent WordPress, soit dans les files d'attente, soit dans la limite de la RAM. Je d\u00e9termine la taille du processus, je r\u00e9serve de la m\u00e9moire pour les services syst\u00e8me et je d\u00e9finis pm.max_children avec une m\u00e9moire tampon. Ensuite, je contr\u00f4le pm.max_requests, request_terminate_timeout et le mode pm = dynamic ou static selon l'image de charge. La mise en cache, OPcache et des plugins propres r\u00e9duisent sensiblement le nombre de requ\u00eates PHP. En appliquant ces mesures de mani\u00e8re cons\u00e9quente, les pages restent r\u00e9actives et le serveur fiable.<\/p>","protected":false},"excerpt":{"rendered":"<p>De faux **PHP-FPM Children** bloquent les sites WordPress. Apprends \u00e0 r\u00e9gler le php-fpm wordpress pour une performance parfaite de wp php children et d'h\u00e9bergement.<\/p>","protected":false},"author":1,"featured_media":17351,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[733],"tags":[],"class_list":["post-17358","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"1371","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"PHP-FPM Children","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"17351","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=17358"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17358\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/17351"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=17358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=17358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=17358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}