{"id":18921,"date":"2026-04-11T08:37:18","date_gmt":"2026-04-11T06:37:18","guid":{"rendered":"https:\/\/webhosting.de\/php-request-queueing-max-children-verarbeitungslimits-performance\/"},"modified":"2026-04-11T08:37:18","modified_gmt":"2026-04-11T06:37:18","slug":"php-request-queueing-max-children-limites-de-traitement-performance","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/php-request-queueing-max-children-verarbeitungslimits-performance\/","title":{"rendered":"Mise en file d'attente des requ\u00eates PHP et limites de traitement : configuration optimale pour des serveurs stables"},"content":{"rendered":"<p>La mise en file d'attente des requ\u00eates PHP limite le nombre de requ\u00eates trait\u00e9es simultan\u00e9ment par ton serveur et d\u00e9termine ainsi le temps de r\u00e9ponse, le taux d'erreur et l'exp\u00e9rience utilisateur. Je vais te montrer comment <strong>Limites de traitement<\/strong> Le but est d'\u00e9liminer les goulets d'\u00e9tranglement et d'obtenir une livraison constante gr\u00e2ce \u00e0 des param\u00e8tres harmonis\u00e9s.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Pour que tu puisses commencer tout de suite, je r\u00e9sume les principales vis de r\u00e9glage pour <strong>PHP-FPM<\/strong> ensemble.<\/p>\n<ul>\n  <li><strong>pm.max_children<\/strong>: calculer la limite sup\u00e9rieure des processus PHP simultan\u00e9s, en fonction de la RAM.<\/li>\n  <li><strong>listen.backlog<\/strong>: Maximiser la mise en m\u00e9moire tampon \u00e0 court terme des tentatives de connexion lors des pics de charge.<\/li>\n  <li><strong>pm.max_requests<\/strong>: recycler r\u00e9guli\u00e8rement les processus afin d'\u00e9viter les fuites de m\u00e9moire et le gonflement.<\/li>\n  <li><strong>Timeouts<\/strong>: d\u00e9finir de mani\u00e8re coh\u00e9rente request_terminate_timeout, max_execution_time et les timeouts du serveur web.<\/li>\n  <li><strong>M\u00e9triques<\/strong>: max children reached, listen queue et slowlogs \u00e0 v\u00e9rifier en permanence.<\/li>\n<\/ul>\n<p>Je mise sur des indicateurs clairs et des effets mesurables pour que chaque adaptation \u00e0 des <strong>Limites<\/strong> reste compr\u00e9hensible. Pour chaque modification, j'observe les logs et les temps de r\u00e9ponse avant de planifier la prochaine \u00e9tape et d'augmenter ou de diminuer progressivement les valeurs. J'\u00e9vite ainsi des effets secondaires tels que le memory swapping, qui peut affecter chaque <strong>Queue<\/strong> se prolonge de mani\u00e8re spectaculaire. En proc\u00e9dant de la sorte, je ram\u00e8ne les pics de charge \u00e0 des proportions plus raisonnables et maintiens les temps de r\u00e9ponse \u00e0 un niveau stable. L'objectif est d'obtenir une charge de travail \u00e9quilibr\u00e9e, qui <strong>Ressources<\/strong> sans surcharger l'h\u00f4te.<\/p>\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\/04\/serveroptimierung-php-req-queue-8453.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment la mise en file d'attente des requ\u00eates PHP fonctionne dans PHP-FPM<\/h2>\n<p>Chaque requ\u00eate HTTP entrante n\u00e9cessite un <strong>Travailleur<\/strong>, et un worker ne traite qu'une seule demande \u00e0 la fois. Si tous les processus sont occup\u00e9s, d'autres appels atterrissent dans la <strong>Queue<\/strong> et attendre qu'un processus se lib\u00e8re. Si cette file d'attente augmente, les temps de r\u00e9ponse s'allongent et des erreurs comme 502\/504 se produisent plus souvent. Je veille donc \u00e0 un rapport raisonnable entre le nombre de processus et la m\u00e9moire disponible, plut\u00f4t que de miser aveugl\u00e9ment sur un parall\u00e9lisme maximal. J'obtiens ainsi un d\u00e9bit constant sans que <strong>RAM<\/strong> ou de l'unit\u00e9 centrale.<\/p>\n\n<h2>Choisir proprement les modes du gestionnaire de processus<\/h2>\n<p>Outre les valeurs limites, c'est le <strong>mode pm<\/strong> sur la r\u00e9activit\u00e9 et la consommation de ressources :<\/p>\n<ul>\n  <li><strong>pm = dynamique<\/strong>Je d\u00e9finis start_servers, min_spare_servers et max_spare_servers. Ce mode est mon standard pour les charges variables, parce qu'il r\u00e9agit rapidement aux mont\u00e9es et tient des processus chauds \u00e0 disposition.<\/li>\n  <li><strong>pm = ondemand<\/strong>: Les processus ne sont cr\u00e9\u00e9s qu'en cas de besoin et sont termin\u00e9s apr\u00e8s process_idle_timeout. Cela permet d'\u00e9conomiser de la RAM en cas d'acc\u00e8s peu fr\u00e9quents (admin, staging, endpoints cron), mais peut \u00eatre probl\u00e9matique en cas de pics soudains. <strong>d\u00e9marrages \u00e0 froid<\/strong> et g\u00e9n\u00e9rer une latence plus \u00e9lev\u00e9e. Je l'utilise donc de mani\u00e8re cibl\u00e9e et avec un backlog g\u00e9n\u00e9reux.<\/li>\n  <li><strong>pm = static<\/strong>: Un nombre fixe de processus. Id\u00e9al si j'ai une <strong>plafond dur<\/strong> et des latences particuli\u00e8rement pr\u00e9visibles (p. ex. proxy L7 devant quelques points finaux critiques). Les besoins en RAM sont clairement calculables, mais les processus inutilis\u00e9s consomment de la m\u00e9moire.<\/li>\n<\/ul>\n<p>Je d\u00e9cide pour chaque pool quel mode convient au profil. Pour les frontaux \u00e0 charge variable, j'utilise g\u00e9n\u00e9ralement dynamic, pour les pools utilitaires ondemand et pour les services d\u00e9di\u00e9s \u00e0 latence critique, \u00e9ventuellement static.<\/p>\n\n<h2>d\u00e9terminer correctement pm.max_children<\/h2>\n<p>Le levier le plus important est <strong>pm.max_children<\/strong>, car cette valeur d\u00e9finit le nombre de requ\u00eates qui peuvent \u00eatre ex\u00e9cut\u00e9es simultan\u00e9ment. Je calcule la taille de d\u00e9marrage avec la formule empirique : (RAM disponible - 2 Go de r\u00e9serve) divis\u00e9 par la m\u00e9moire moyenne par processus PHP. En gros, je pr\u00e9vois 40-80 Mo par processus et je d\u00e9marre avec 200-300 processus sur un h\u00f4te de 32 Go. Sous charge r\u00e9elle, j'augmente ou je diminue progressivement et je v\u00e9rifie si le temps d'attente des <strong>Queue<\/strong> et le taux d'erreur diminue. Pour ceux qui souhaitent aller plus loin, vous trouverez des informations sur les valeurs de d\u00e9part et les valeurs limites sous <a href=\"https:\/\/webhosting.de\/fr\/php-fpm-gestion-des-processus-pm-max-children-optimiser-core\/\">Optimiser pm.max_children<\/a>.<\/p>\n\n<h2>Coordonner les valeurs de d\u00e9part, de r\u00e9serve et de backlog<\/h2>\n<p>Je mets <strong>pm.start_servers<\/strong> \u00e0 environ 15-30% de pm.max_children, afin qu'il y ait suffisamment de processus pr\u00eats au d\u00e9but et qu'il n'y ait pas de d\u00e9marrages \u00e0 froid. Avec pm.min_spare_servers et pm.max_spare_servers, je d\u00e9finis une fen\u00eatre raisonnable pour les processus libres, afin que les nouvelles requ\u00eates n'attendent pas et qu'en m\u00eame temps, aucun ralenti inutile ne mobilise de la m\u00e9moire. Listen.backlog est particuli\u00e8rement important : Cette m\u00e9moire tampon du noyau retient bri\u00e8vement les tentatives de connexion suppl\u00e9mentaires lorsque tous les travailleurs sont occup\u00e9s. En cas de pics de charge, je fixe des valeurs \u00e9lev\u00e9es (par exemple 65535) pour que les <strong>file d'attente<\/strong> ne s'arr\u00eate pas avant le pool FPM. Pour plus d'informations sur l'interaction entre le serveur web, le flux montant et les tampons, voir l'aper\u00e7u de <a href=\"https:\/\/webhosting.de\/fr\/serveur-web-file-dattente-latence-traitement-des-requetes-file-dattente-du-serveur\/\">Mise en file d'attente du serveur web<\/a>.<\/p>\n\n<h2>Limiter les temps d'ex\u00e9cution des requ\u00eates et recycler les processus<\/h2>\n<p>J'\u00e9vite les remont\u00e9es de m\u00e9moire insidieuses avec <strong>pm.max_requests<\/strong>, qui red\u00e9marre chaque processus apr\u00e8s X requ\u00eates. Les applications discr\u00e8tes fonctionnent souvent bien avec 500-800, si je soup\u00e7onne des fuites de m\u00e9moire, je r\u00e9duis \u00e0 100-200 et j'observe l'effet. De plus, request_terminate_timeout encapsule les d\u00e9rives en mettant fin aux requ\u00eates extr\u00eamement longues apr\u00e8s une dur\u00e9e fixe. La coh\u00e9rence est importante : je maintiens le max_execution_time de PHP et les timeouts du serveur web dans le m\u00eame corridor, afin qu'une couche ne s'arr\u00eate pas plus t\u00f4t que l'autre. Cette interaction maintient <strong>Travailleur<\/strong> et prot\u00e8ge la piscine de la congestion.<\/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\/04\/PHP_Server_Limits_Besprechung_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rendre les files d'attente visibles : Logs et m\u00e9triques<\/h2>\n<p>Je lis r\u00e9guli\u00e8rement les logs FPM et je fais attention \u00e0 <strong>max children reached<\/strong>, Cette entr\u00e9e indique que la limite sup\u00e9rieure des processus a \u00e9t\u00e9 atteinte. En parall\u00e8le, j'observe la file d'attente des listes, qui permet de d\u00e9tecter une accumulation croissante dans le tampon d'entr\u00e9e. En combinaison avec request_slowlog_timeout, j'obtiens des traces de la pile aux endroits lents du code et j'isole les freins de la base de donn\u00e9es ou de l'API. Je corr\u00e8le upstream_response_time des logs du serveur web avec request_time et les codes d'\u00e9tat pour limiter la source des longs temps de r\u00e9ponse. Je peux ainsi d\u00e9terminer si le goulot d'\u00e9tranglement dans PHP-FPM, le <strong>Base de donn\u00e9es<\/strong> ou le r\u00e9seau en amont.<\/p>\n\n<h2>Profils de charge de travail : Li\u00e9 au CPU vs. li\u00e9 \u00e0 l'IO<\/h2>\n<p>Pour les processus n\u00e9cessitant beaucoup de CPU, je mets \u00e0 l'\u00e9chelle les <strong>Parall\u00e9lisme<\/strong> Je suis prudent et m'oriente \u00e9troitement vers le nombre de vCPU, car les processus suppl\u00e9mentaires n'apportent gu\u00e8re de d\u00e9bit. S'il s'agit principalement d'une charge IO avec acc\u00e8s \u00e0 une base de donn\u00e9es ou \u00e0 des API externes, je peux autoriser plus de processus tant que le budget RAM est suffisant. Les contr\u00f4les du commerce \u00e9lectronique profitent de d\u00e9lais d'attente plus longs (par exemple 300 s) pour achever les chemins de paiement sans interruption. J'intercepte les ventes flash en augmentant la valeur de listen.backlog et en agrandissant la fen\u00eatre de spare. Des conseils sur l'\u00e9quilibre entre le nombre de processus et la performance de l'h\u00f4te sont donn\u00e9s dans le guide de <a href=\"https:\/\/webhosting.de\/fr\/php-workers-hosting-goulot-detranglement-guide-balance\/\">PHP-Workers comme goulot d'\u00e9tranglement<\/a>.<\/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\/04\/php-request-queue-servers-6591.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemples de calcul et de dimensionnement<\/h2>\n<p>Je calcule tout d'abord la m\u00e9moire par processus et j'en d\u00e9duis une valeur raisonnable. <strong>Plafond<\/strong> de la file d'attente. Ensuite, je teste sous charge r\u00e9elle et j'observe si la file d'attente diminue et si le d\u00e9bit augmente. Des valeurs de d\u00e9part conservatrices r\u00e9duisent le risque de swapping et maintiennent un temps de r\u00e9action r\u00e9gulier. Ensuite, j'affine par petites \u00e9tapes pour \u00eatre s\u00fbr de remarquer les effets secondaires. Le tableau suivant fournit des conseils sur les valeurs de d\u00e9part et les effets sur la <strong>Queue<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Effet<\/th>\n      <th>Valeur de d\u00e9part (exemple)<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>pm.max_children<\/td>\n      <td>Nombre max. d'utilisateurs simultan\u00e9s <strong>Processus<\/strong><\/td>\n      <td>200-300 (pour 32 Go)<\/td>\n      <td>Comparer avec le budget RAM et la taille du processus<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.start_servers<\/td>\n      <td>Nombre initial de travailleurs<\/td>\n      <td>15-30 % de max_children<\/td>\n      <td>\u00c9viter les d\u00e9marrages \u00e0 froid, mais maintenir le ralenti au minimum<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.min_spare_servers<\/td>\n      <td>Libre <strong>Travailleur<\/strong> Minimum<\/td>\n      <td>z. B. 20<\/td>\n      <td>Enregistrement direct de nouvelles requ\u00eates<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_spare_servers<\/td>\n      <td>Travailleur libre Maximum<\/td>\n      <td>z. B. 40<\/td>\n      <td>Limiter l'utilisation de la RAM par les processus inertes<\/td>\n    <\/tr>\n    <tr>\n      <td>listen.backlog<\/td>\n      <td>M\u00e9moire tampon du noyau pour les tentatives de connexion<\/td>\n      <td>65535<\/td>\n      <td>Amortir les pics de charge et r\u00e9duire les pertes de connexion<\/td>\n    <\/tr>\n    <tr>\n      <td>pm.max_requests<\/td>\n      <td>recyclage <strong>Intervalle<\/strong><\/td>\n      <td>500-800, en cas de fuites 100-200<\/td>\n      <td>Minimiser le gonflement de la m\u00e9moire et les accrocs<\/td>\n    <\/tr>\n    <tr>\n      <td>request_terminate_timeout<\/td>\n      <td>Limite de requ\u00eates dure<\/td>\n      <td>300-600 s<\/td>\n      <td>Coh\u00e9rent avec les timeouts de PHP et du serveur web<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Mod\u00e8les pratiques pour les pools PHP-FPM<\/h2>\n<p>Pour une boutique avec beaucoup d'acc\u00e8s en lecture, je mets mod\u00e9r\u00e9ment <strong>Chiffres du processus<\/strong> et augmente la fen\u00eatre Spare pour que les requ\u00eates ne soient pas en attente. Pour les pages de contenu avec mise en cache, il suffit souvent de beaucoup moins de worker, tant que NGINX ou Apache fournissent efficacement des contenus statiques. Je s\u00e9pare les configurations multi-pools selon les parties de l'application qui ont des profils de m\u00e9moire diff\u00e9rents, afin qu'aucun pool lourd ne supplante les autres. Pour les travailleurs Cron ou Queue, je d\u00e9finis des pools s\u00e9par\u00e9s avec leur propre ensemble de r\u00e8gles de timeout. C'est ainsi que je maintiens l'interactivit\u00e9 <strong>Trafic<\/strong> libre et ne freine pas les actions des utilisateurs.<\/p>\n\n<h2>Timeouts du serveur web, upstream et sockets<\/h2>\n<p>Je consid\u00e8re les d\u00e9lais FastCGI et Proxy de <strong>Nginx<\/strong> ou Apache dans la m\u00eame fen\u00eatre que les timeouts FPM, afin qu'aucune couche ne s'arr\u00eate trop t\u00f4t. Je pr\u00e9f\u00e8re les sockets Unix \u00e0 TCP, \u00e0 condition que les deux services fonctionnent sur le m\u00eame h\u00f4te, car la latence reste minimale. Pour les configurations distribu\u00e9es, j'utilise TCP avec des valeurs keepalive stables et un pool de connexions suffisamment grand. Pour un parall\u00e9lisme \u00e9lev\u00e9, nginx coordonne les worker_connections et les valeurs de backlog FPM. Ainsi, les transferts restent rapides et j'\u00e9vite les temps morts dus \u00e0 des connexions trop \u00e9troites. <strong>en amont<\/strong>-limites.<\/p>\n\n<h2>Mise en cache, OPCache et base de donn\u00e9es comme leviers de commande<\/h2>\n<p>Je r\u00e9sous de nombreux probl\u00e8mes de serveur en r\u00e9duisant les op\u00e9rations co\u00fbteuses et en <strong>Temps de r\u00e9ponse<\/strong> de la m\u00e9moire. J'active l'OPCache, j'augmente judicieusement la limite de m\u00e9moire du cache et je veille \u00e0 ce que le d\u00e9bit du cache soit \u00e9lev\u00e9. Pour les r\u00e9sultats r\u00e9currents, j'utilise la mise en cache des applications pour que les processus PHP se terminent plus rapidement. C\u00f4t\u00e9 base de donn\u00e9es, j'optimise les requ\u00eates lentes et j'active des caches de requ\u00eates adapt\u00e9s au syst\u00e8me utilis\u00e9. Chaque milliseconde \u00e9conomis\u00e9e soulage les <strong>Queue<\/strong> et augmente le d\u00e9bit par travailleur.<\/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\/04\/php_server_setup_8943.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e9curiser les m\u00e9canismes d'urgence et les red\u00e9marrages<\/h2>\n<p>J'active <strong>seuil_red\u00e9marrage_d'urgence<\/strong> et emergency_restart_interval, afin que le ma\u00eetre FPM red\u00e9marre si trop d'enfants se crashent rapidement les uns apr\u00e8s les autres. Ce red\u00e9marrage contr\u00f4l\u00e9 emp\u00eache les r\u00e9actions en cha\u00eene et maintient le service disponible. Parall\u00e8lement, je fixe des limites claires pour la m\u00e9moire et le nombre de processus afin d'amortir les escalades. Les contr\u00f4les de sant\u00e9 en amont retirent automatiquement les backends d\u00e9fectueux du pool et r\u00e9duisent les taux d'erreur. Ainsi, la <strong>Disponibilit\u00e9<\/strong> pendant que j'enqu\u00eate sur la cause r\u00e9elle.<\/p>\n\n<h2>Ajuster finement les limites du syst\u00e8me d'exploitation et de Systemd<\/h2>\n<p>Avec cela, <strong>listen.backlog<\/strong> s'applique effectivement, je compense les limites du noyau. La valeur OS net.core.somaxconn doit \u00eatre au moins aussi \u00e9lev\u00e9e que le backlog d\u00e9fini, sinon le syst\u00e8me coupe la file d'attente. Je v\u00e9rifie \u00e9galement le nombre de descripteurs de fichiers autoris\u00e9s : Dans le pool FPM, je peux d\u00e9finir rlimit_files, au niveau du service je s\u00e9curise LimitNOFILE (systemd) et au niveau du noyau fs.file-max. Le serveur web a besoin de r\u00e9serves similaires pour ne pas atteindre ses limites plus t\u00f4t.<\/p>\n<p>Pour des latences plus stables, je r\u00e9duis <strong>vm.swappiness<\/strong>, afin que le noyau ne d\u00e9place pas pr\u00e9matur\u00e9ment les pages m\u00e9moire utilis\u00e9es activement. Dans les configurations o\u00f9 la latence est critique, je d\u00e9sactive <strong>Pages transparentes volumineuses<\/strong>, pour \u00e9viter les longs d\u00e9fauts de page. Si FPM fonctionne via TCP, je compare \u00e9galement net.ipv4.tcp_max_syn_backlog et les param\u00e8tres Reuse\/Keepalive. De tels d\u00e9tails du syst\u00e8me d'exploitation semblent insignifiants, mais ils d\u00e9terminent si les files d'attente <em>lisse<\/em> ou si les connexions sont d\u00e9j\u00e0 rejet\u00e9es avant FPM.<\/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\/04\/php_request_queue_8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mesurer la m\u00e9moire par processus de mani\u00e8re r\u00e9siliente<\/h2>\n<p>Au lieu d'estimer globalement, je mesure le <strong>Consommation r\u00e9elle<\/strong> par travailleur sous charge r\u00e9elle. J'utilise des outils comme ps, smem ou pmap, je filtre sur les enfants php-fpm et je fais la moyenne des valeurs RSS pendant que des requ\u00eates sont en cours. Il est important de tenir compte de l'utilisation commune et partag\u00e9e de l'OPCache : on ne compte pas plusieurs fois la m\u00e9moire partag\u00e9e. A partir de la valeur moyenne, je d\u00e9duis pm.max_children et je pr\u00e9vois en plus une r\u00e9serve pour que la machine ne se mette pas en d\u00e9faut m\u00eame en cas de pics. <strong>\u00e9change<\/strong> bascule.<\/p>\n<p>Je r\u00e9p\u00e8te cette mesure apr\u00e8s des changements de fonctionnalit\u00e9s ou de versions. De nouvelles fonctionnalit\u00e9s, davantage de d\u00e9pendances ou des modifications de frameworks peuvent augmenter consid\u00e9rablement l'empreinte par processus. Ainsi, le nombre de processus reste r\u00e9aliste et la file d'attente courte.<\/p>\n\n<h2>\u00c9tat PHP-FPM, ping et m\u00e9triques vivantes<\/h2>\n<p>Pour une \u00e9valuation rapide de la situation, j'active <strong>pm.status_path<\/strong> et un <strong>Point final de ping<\/strong> (ping.path\/ping.response). J'y vois des indicateurs comme accepted conn, listen queue len, idle\/busy processes, max children reached et leur \u00e9volution. Je lis p\u00e9riodiquement ces valeurs et fixe des seuils : si listen queue augmente durablement, j'augmente soit les processus, soit je supprime la cause des requ\u00eates lentes. Si max children reached se d\u00e9clenche alors que idle reste bas, le pool est trop petit ou bloqu\u00e9 par <strong>coureur long<\/strong>.<\/p>\n<p>De plus, je s\u00e9pare les pools avec diff\u00e9rents profils afin que les pics dans un domaine (par ex. les importations API) ne mettent pas le trafic interactif \u00e0 genoux. Pour les cas de diagnostic, j'augmente temporairement le log_level et je laisse le slowlog capturer plus d'\u00e9chantillons, mais je le r\u00e9duis ensuite pour maintenir la charge I\/O \u00e0 un faible niveau.<\/p>\n\n<h2>T\u00e9l\u00e9chargements, mise en m\u00e9moire tampon et gros volumes de requ\u00eates<\/h2>\n<p>Les gros t\u00e9l\u00e9chargements peuvent mobiliser inutilement les travailleurs si PHP doit d'abord lire le corps de la requ\u00eate. Je fais en sorte que le serveur web <strong>tamponne<\/strong> (par exemple fastcgi_request_buffering chez NGINX), de sorte que FPM ne d\u00e9marre que lorsque le corps est complet. Ainsi, aucun worker ne se bloque pendant le t\u00e9l\u00e9chargement. Avec client_max_body_size, post_max_size et max_input_time, je contr\u00f4le la taille et la dur\u00e9e des requ\u00eates sans mettre en danger les points finaux. Si des fichiers sont en attente, j'attribue une m\u00e9moire temporaire (SSD) suffisamment rapide pour \u00e9viter les bourrages dans la m\u00e9moire tampon.<\/p>\n<p>Pour les points de terminaison avec de tr\u00e8s grands corps (par ex. exportations\/importations), je d\u00e9finis des pools d\u00e9di\u00e9s avec leurs propres timeouts et un parall\u00e9lisme r\u00e9duit. Ainsi, les workers standard restent libres et les <strong>Queue<\/strong> des actions importantes des utilisateurs bri\u00e8vement.<\/p>\n\n<h2>Connexions \u00e0 la base de donn\u00e9es et limites du pool<\/h2>\n<p>Le meilleur r\u00e9glage du FPM ne sert \u00e0 rien si les <strong>Base de donn\u00e9es<\/strong> \u00e9tait auparavant limit\u00e9. J'aligne le nombre maximal de processus PHP simultan\u00e9s sur la capacit\u00e9 r\u00e9elle de la base de donn\u00e9es. Pour les connexions persistantes ou les pools de connexions, je fais en sorte que la somme de tous les pools <em>\u00e0 l'adresse suivante :<\/em> max_connections reste. Si de nombreuses requ\u00eates courtes sont cr\u00e9\u00e9es, il est utile de limiter mod\u00e9r\u00e9ment le parall\u00e9lisme PHP afin que la base de donn\u00e9es ne soit pas thrash\u00e9e entre des milliers de sessions.<\/p>\n<p>Les transactions lentes provoquent rapidement un embouteillage jusque dans la file d'attente FPM. C'est pourquoi j'analyse les temps d'attente de verrouillage, l'utilisation des index et les plans de requ\u00eate. Toute r\u00e9duction du temps d'ex\u00e9cution de la base de donn\u00e9es r\u00e9duit imm\u00e9diatement la dur\u00e9e de la requ\u00eate PHP.<strong>Dur\u00e9e du document<\/strong> et r\u00e9duit les longueurs de file d'attente.<\/p>\n\n<h2>Sorties et d\u00e9ploiements sans spike<\/h2>\n<p>Lorsque je d\u00e9ploie de nouvelles versions, j'\u00e9vite les caches froids et les temp\u00eates de processus. J'utilise <strong>reload<\/strong> au lieu de red\u00e9marrages brutaux, afin que les requ\u00eates de travail existantes se terminent proprement (respecter process_control_timeout). J'\u00e9chauffe l'OPCache \u00e0 l'avance en parcourant les chemins critiques avant la commutation ou en travaillant avec le pr\u00e9chargement. J'\u00e9vite ainsi que de nombreux workers analysent simultan\u00e9ment des fichiers de classe et que les <strong>Temps de r\u00e9ponse<\/strong> augmente brusquement.<\/p>\n<p>Dans les strat\u00e9gies Blue\/Green ou Canary, je laisse la charge augmenter progressivement et j'observe les pages d'\u00e9tat. Ce n'est que lorsque la file d'attente, le taux d'erreur et les latences restent stables que j'augmente la part de trafic. Cette proc\u00e9dure contr\u00f4l\u00e9e permet d'\u00e9viter les pics de charge pendant le d\u00e9ploiement.<\/p>\n\n<h2>Sp\u00e9cificit\u00e9s des conteneurs et des VM<\/h2>\n<p>Dans les conteneurs, la perception <strong>Quantit\u00e9 totale de m\u00e9moire<\/strong> souvent inf\u00e9rieur \u00e0 celui annonc\u00e9 par l'h\u00f4te. J'aligne strictement pm.max_children sur la limite de cgroup et je pr\u00e9vois une r\u00e9serve contre le tueur d'OOM. Les limites de m\u00e9moire en PHP (memory_limit) et l'empreinte par processus doivent aller de pair, sinon il suffit d'un seul \u00e9cart pour que le conteneur se termine.<\/p>\n<p>Si le swap est absent du conteneur, les ruptures difficiles sont plus probables. C'est pourquoi je garde les processus conservateurs, j'active le recyclage, et je surveille les pics de RSS en charge de production. Plusieurs pools all\u00e9g\u00e9s sont ici souvent plus robustes qu'un grand pool monolithique.<\/p>\n\n<h2>D\u00e9gradation et backpressure contr\u00f4lables<\/h2>\n<p>Si la <strong>Queue<\/strong> plus vite qu'elle ne peut \u00eatre r\u00e9duite, je mise sur une d\u00e9gradation contr\u00f4l\u00e9e : en cas de surcharge, je livre d\u00e9lib\u00e9r\u00e9ment 503 avec Retry-After pour les points finaux non critiques, je r\u00e9duis les fonctionnalit\u00e9s co\u00fbteuses (par ex. recherche en direct) et je limite les acc\u00e8s parall\u00e8les aux hotspots. De cette mani\u00e8re, le syst\u00e8me reste accessible pendant que je corrige la cause, au lieu que tous les utilisateurs soient mis en attente.<\/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\/04\/php-serverraum-1635.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En bref<\/h2>\n<p>J'apporte <strong>Mise en file d'attente des requ\u00eates PHP<\/strong> en faisant correspondre intelligemment le nombre de processus simultan\u00e9s au budget RAM et au type de charge. Des valeurs de backlog \u00e9lev\u00e9es amortissent les pics, les d\u00e9lais d'attente \u00e0 tous les niveaux s'imbriquent proprement et le recyclage \u00e9limine les probl\u00e8mes de m\u00e9moire insidieux. Les logs et les m\u00e9triques me montrent si la file d'attente augmente, o\u00f9 les requ\u00eates sont bloqu\u00e9es et quand je dois les affiner. Gr\u00e2ce \u00e0 des adaptations prudentes et \u00e0 une mise en cache cibl\u00e9e, je r\u00e9duis le temps de traitement par requ\u00eate et j'augmente le d\u00e9bit. Ainsi, les serveurs fournissent des donn\u00e9es coh\u00e9rentes et \u00e9vitent les erreurs co\u00fbteuses. <strong>Timeouts<\/strong> dans la vie quotidienne.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ma\u00eetriser la mise en file d'attente des requ\u00eates PHP : configurer max children php et Server Queue Handling de mani\u00e8re optimale. Guide avec des conseils pratiques pour des performances stables sous charge.<\/p>","protected":false},"author":1,"featured_media":18914,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-18921","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"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":"405","_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 Request Queueing","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":"18914","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18921","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=18921"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/18921\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/18914"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=18921"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=18921"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=18921"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}