Comparaison des modes PHP-FPM : Static, Dynamic et Ondemand

Cet article compare les modes de PHP-FPM static, dynamique et ondemand et montre comment ils démarrent les processus, lient la RAM et influencent la latence. J'explique de manière pratique quand quel mode est convaincant, je fournis des valeurs de démarrage judicieuses, je cite des écueils typiques et je montre des astuces de monitoring pour que tu puisses utiliser tes PHP-de la piscine.

Points centraux

Pour que tu puisses te lancer rapidement, je vais résumer de manière compacte les déclarations les plus importantes. L'accent est mis sur le contrôle des processus, les besoins en RAM, la latence et les domaines d'application. Chaque choix a des points forts clairs, mais aussi des limites. Avec quelques chiffres clés, tu peux prendre des décisions solides. Voici comment aborder le sujet de manière ciblée Tuning et tu gagnes du temps.

• Statique: nombre de processus fixe, constance maximale à charge constante.
• Dynamique: mise à l'échelle automatique entre les valeurs minimales et maximales.
• Ondemand: démarrage à la demande, économique au ralenti, latence de démarrage à froid.
• Planification de la RAM: Prévoir 20 à 50 Mo par processus, éviter les OOM.
• Suivi: page d'état, logs et htop pour des décisions éclairées.

Fonctionnement du gestionnaire de processus

Le gestionnaire de processus PHP-FPM contrôle combien de Travailleur-Les processus Worker traitent les demandes et quand elles se produisent ou se terminent. Chaque instance de worker conserve en mémoire l'interpréteur, les extensions et une partie du bytecode, ce qui représente en général quelques minutes par processus. Mégaoctets de la voiture. Les trois modes modifient fortement le comportement au démarrage, le cycle de vie et le comportement au ralenti. Static maintient un nombre fixe actif, Dynamic équilibre entre les limites inférieures et supérieures, Ondemand ne génère des processus qu'en cas de requêtes entrantes. Ce contrôle agit directement sur RAM-Le profil d'utilisation, la latence à l'ouverture et les pics de charge du système.

Des paramètres importants forment la colonne vertébrale de ta configuration : pm détermine le mode, pm.max_children limite les travailleurs simultanés. Avec Dynamic, les pm.start_servers, pm.min_spare_servers et pm.max_spare_servers qui contrôlent la largeur de la mémoire tampon. Ondemand mise sur pm.process_idle_timeout, pour mettre fin aux processus en sommeil. Avec des valeurs raisonnables, tu t'assures que les pics de charge n'entraînent pas de goulots d'étranglement et que la machine ne subisse pas de pression de mémoire.

Je vérifie au préalable l'empreinte par processus, la charge moyenne simultanée et la répartition des pics sur la journée. A partir de ces grandeurs, je déduis la valeur maximale pour pm.max_children multiplier par la mémoire de processus mesurée et laisser une réserve pour le serveur web, la base de données, le cache et le noyau. Ce calcul simple permet d'éviter les erreurs de mémoire non utilisée et garantit Stabilité sous pression. Si l'on y prend garde, on s'épargnera par la suite de pénibles réajustements.

Mode statique : puissance constante pour une charge uniforme

Le mode statique maintient un nombre fixe de travailleurs PHP actifs en permanence, ce qui Lancement-est éliminée. Avec des profils de trafic constants, cette configuration permet d'obtenir de très faibles variations de latence et une qualité d'image régulière. CPU-charge de travail. Le revers de la médaille : La RAM reste occupée au ralenti, bien qu'il n'y ait pas de requêtes. C'est pourquoi je ne choisis Static que sur les hôtes disposant de beaucoup de mémoire et d'un volume de requêtes calculable. Sur les boutiques très utilisées ou les backends API, Static fournit souvent la courbe de réaction la plus propre.

Ce qui compte, c'est de fixer un objectif réaliste pm.max_children, qui s'oriente sur l'empreinte du processus. Pour la première estimation, je compte en gros 20-50 Mo par processus PHP, extensions et OPcache inclus. Je vérifie la valeur finale avec des tests de charge et le moniteur système. Ceux qui souhaitent approfondir le calcul trouveront des étapes pratiques sous Optimiser pm.max_children. Tu t'assureras ainsi que la taille fixe de ta piscine correspond à ton matériel.

[www]
pm = static
pm.max_children = 50
pm.max_requests = 500

RemarqueAprès les modifications, je redémarre PHP-FPM, je vérifie les journaux et j'observe la charge de travail dans le trafic réel. S'il reste beaucoup de RAM, je l'augmente prudemment. Si je vois une augmentation de l'utilisation du swap ou des entrées OOM-Killer, je réduis immédiatement. Cette petite routine protège les Disponibilité fiable.

Mode dynamique : flexible en cas de demande fluctuante

Dynamic démarre avec peu de processus et fait évoluer les Travailleur-dans la fourchette définie en fonction des besoins. Cela permet de réduire la consommation à vide pendant les phases calmes et d'amortir les pics courts. Le procédé génère un peu d'overhead lors du spawning, mais il marque des points avec une bonne qualité. Ressources-efficacité de l'appareil. Dans les environnements mixtes avec des profils journaliers, Dynamic fournit souvent le meilleur compromis. Ce mode reste le premier choix, notamment pour de nombreuses installations CMS.

Je définis les valeurs de départ, minimales et maximales de manière à ce qu'il n'y ait pas de spawn-events permanents en cas de charge typique. Des messages de log fréquents tels que „seems busy, spawning children“ indiquent que les limites sont trop étroites. Pour les piles WordPress, il est utile de régler proprement la mise en cache et l'OPcache, puis de les augmenter modérément. Un guide compact couvre les principaux leviers : paramètres optimaux de WordPress. Tu obtiens ainsi des temps de réponse courts, sans RAM-réserve à faire exploser.

[www]
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

ConseilObserve les travailleurs au repos et la moyenne des processus actifs au cours de la journée. Si la valeur moyenne est proche de la limite supérieure, augmente modérément. Si de nombreux processus restent inactifs, diminue la fourchette. En quelques itérations, tu atteindras la limite. Zone de frappe-réglage.

Mode Ondemand : économe au ralenti, démarrage à la demande

Ondemand ne crée des processus que lorsqu'une Demande et l'arrête après une période d'inactivité. Ainsi, le besoin en RAM est réduit au minimum pendant les phases de calme, ce qui favorise de nombreux petits sites sur une machine. Lors des démarrages à froid, il y a toutefois une latence supplémentaire, car le worker démarre d'abord et se réchauffe. Pour les environnements de développement, les applications cron-only et les sites rarement appelés, cette logique est une Bénéfice. Je n'utiliserais pas Ondemand en cas de charge permanente.

[www]
pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s
pm.max_requests = 500

Je contrôle généralement le temps d'inactivité entre 10 et 30 secondes, en fonction du modèle d'appel et du budget mémoire. Un délai plus court permet d'économiser RAM, mais augmente le risque de démarrage à froid. Un délai plus long garde les processus au chaud, mais coûte de la mémoire. J'observe donc la fréquence d'appel, je mesure la latence du 95e centile et j'ajuste ensuite finement. Ainsi, la Temps de réponse calculable sans alourdir le système.

Tableau comparatif : caractéristiques des trois modes

L'aperçu suivant compare des caractéristiques typiques. Je m'en sers comme base de discussion avant de passer au dimensionnement concret. Le tableau ne remplace pas une mesure sous charge réelle, mais il fournit un aperçu structuré de la situation. Point de départ. Celui qui adapte les valeurs doit toujours garder un œil sur le profil de la mémoire et la répartition de la latence. Ainsi, tu restes à Peaks tu es capable d'agir et tu évites les goulets d'étranglement.

Critère	Statique	Dynamique	Ondemand
Processus	Nombre fixe, actif en permanence	Automatiquement entre min/max	Démarrage uniquement en cas de besoin
Utilisation de la RAM	Constamment élevé	Variable (par ex. 200-600 Mo)	Minimum au ralenti (par ex. 50-700 Mo)
Performance	Très uniforme	Bon et adaptable	Bon en cas de faible trafic
Idéal pour	Profils de trafic élevé constants	Demande variable	Beaucoup de sites dormants / Shared
Overhead	Faible	Moyen (spawn/despawn)	Plus élevé lors des démarrages à froid

Le tableau aide à calibrer les attentes et à désigner clairement les priorités. Si tu as besoin de la plus grande constance dans tes réactions, c'est souvent Statique. Compte l'efficacité en cas de charge fluctuante, fonctionne Dynamique généralement plus agréable. Si l'économie est au premier plan, il n'y a pas d'autre solution que d'opter pour une voiture de location. Ondemand sont terminées. Ce sont les valeurs mesurées qui décident à la fin, pas les suppositions.

Calcul des ressources et dimensionnement

J'estime d'abord l'empreinte mémoire par Processus le multiplier par le nombre d'utilisateurs prévu et ajouter 20-30 % de réserve. Je compte également de la place pour Nginx/Apache, la base de données, Redis/Memcached et le noyau. Cette somme ne doit pas dépasser la capacité physique de la RAM, déduction faite de la marge de sécurité. Pour OPcache, je prévois une mémoire dédiée afin que le bytecode ne soit pas déplacé. Avec cette simple Formule je considère que les risques d'OOM sont faibles.

Dans l'étape suivante, je mesure les demandes simultanées via l'état du serveur web et l'APM. La concurrence des pics pour les travailleurs PHP détermine le niveau de pm.max_children doit être. Si la RAM ne suffit pas, j'augmente les hits en cache, je diminue les temps de requête ou je déplace le travail dans des files d'attente. Ce n'est que lorsque ces leviers fonctionnent que j'augmente la taille du pool. Ainsi, la Efficacité élevé et la machine réagit de manière fiable.

Monitoring et recherche d'erreurs

Les bonnes décisions sont basées sur Données. J'active la page d'état PHP-FPM et je lis les processus actifs et inactifs, la longueur des files d'attente et les connexions acceptées. Je vérifie également les journaux d'erreurs pour les avertissements de spawn et les dépassements de temps. Dans htop, j'observe les attentes du CPU, la charge et le swap afin de trouver plus rapidement les goulots d'étranglement. Ces signaux font des pas de réglage compréhensible et évitent de voler à l'aveuglette.

<?php
$status = @file_get_contents('http://localhost/status');
$data = json_decode($status, true);
echo "Active: " . $data['active processes'] . "\n";
echo "Idle: " . $data['idle processes'] . "\n";
?>

Les outils APM montrent les traces et les goulots d'étranglement au niveau des fonctions ou des requêtes. Si j'y trouve des aberrations, j'interviens d'abord au niveau de la mise en cache et des E/S. Ensuite, je vérifie si les limites du pool correspondent au parallélisme réel. Ce n'est que lorsque les goulets d'étranglement des applications sont résolus que cela vaut la peine d'aller plus loin. Capacité dans FPM. Ce processus permet de gagner du temps et de conserver une architecture légère.

Éviter les erreurs de réglage fréquentes

Je vois souvent des objectifs trop élevés max_enfants-sans tenir compte de la RAM. Cela génère des swaps inutiles, de longues phases de garbage collection et, au final, des OOM killers. De même, des limites trop basses sont nuisibles, car elles créent des files d'attente et allongent les temps de réponse. L'absence d'OPcache fait également perdre du temps au processeur et augmente l'empreinte du processus. Avec peu de Chèques avant, ces pièges restent à l'écart.

Un deuxième classique : des délais d'attente inadaptés chez Ondemand, qui entraînent de nombreux démarrages à froid. Un bref essai A/B avec 10, 20 et 30 secondes de délai d'attente permet de résoudre ce problème. Chez Dynamic, des valeurs de spare trop faibles génèrent des spawns constants. Les logs révèlent rapidement ces schémas et guident la prochaine étape. Adaptation de l'espace. Ainsi, ta pile reste réactive.

PHP-FPM dans le contexte d'autres gestionnaires PHP

PHP-FPM est souvent comparé à d'anciennes variantes de CGI ou à des alternatives modernes comme LSAPI. Le choix du gestionnaire influence la gestion des processus, Ressources-et l'isolation des défauts. Comprendre les différences permet de planifier les tampons et les limites de manière plus réaliste. Pour un aperçu rapide, il vaut la peine de faire un petit tour d'horizon. Comparaison des gestionnaires PHP. Ensuite, le choix des modes FPM est nettement plus difficile. plus ciblé de.

Je reste la plupart du temps avec FPM, parce qu'il est mûr, qu'il enregistre proprement et qu'il fonctionne bien avec Nginx/Apache. Ce ne sont pas seulement les benchmarks qui sont décisifs, mais aussi les aspects opérationnels comme l'observabilité et le failover. Si ces bases sont bonnes, tu peux tirer davantage de Static, Dynamic ou Ondemand. Chaque option mérite d'être testée sous une charge réelle. C'est ainsi que tu gagneras en confiance dans tes Paramètres.

Stratégie décisionnelle pratique

Je commence avec Dynamic en tant que Défaut, Je mesure les profils de charge et j'observe les pics. Si je trouve une charge très constante, je passe à Static et je règle la taille fixe du pool. Si je rencontre des sites rarement utilisés, je choisis Ondemand avec un délai d'inactivité approprié. Parallèlement, j'optimise l'OPcache, l'Object Cache et les requêtes de la base de données pour que FPM reçoive moins de pression. Ensuite, j'affine les limites de manière à ce que Files d'attente ne se produisent pas du tout.

Cet ordre permet de réduire les risques et les efforts. D'abord mesurer, ensuite adapter les règles, enfin prendre en compte le matériel. Je documente brièvement chaque modification en indiquant le moment, les valeurs et l'objectif. Cela facilite les corrections ultérieures et garantit la propreté des données. Transparence. Ainsi, la pile reste maîtrisable, même si les modèles de trafic changent.

Des chiffres clés aux valeurs solides : comment je calcule

Je traduis les profils de charge en tailles concrètes de pools avec une règle simple : combien de demandes arrivent par seconde et combien de temps dure le traitement en moyenne ou au 95e percentile ? Pour m'orienter, j'utilise La loi de Little sous une forme simple : exécutions simultanées ≈ débit × temps de traitement moyen. Exemple : 120 requêtes/s à 80 ms en moyenne donnent environ 9,6 exécutions simultanées. J'ajoute 30-50 tampons de % pour les pics et je vérifie si les résultats pm.max_children correspondent à mon budget RAM. Pour les pics difficiles, j'intègre en plus le 95e centile afin d'éviter les files d'attente.

Ce qui est important, c'est d'avoir Caractère des charges de travail : Pour les applications à forte charge d'E/S (nombreux appels distants, accès à la base de données), il est souvent avantageux d'avoir un peu plus de worker, car les temps d'attente se chevauchent. Pour les codes à forte charge CPU, je limite davantage afin que les processus ne se ralentissent pas mutuellement et que la file d'attente d'exécution n'explose pas.

pm.max_requests : recyclage propre contre la fragmentation

Les processus PHP qui s'exécutent depuis longtemps peuvent être interrompus par Fragmentation ou les fuites de mémoire se développent. Avec pm.max_requests tu définis après combien de requêtes traitées un worker est arrêté et redémarré. Cela permet de garder l'empreinte stable. Je commence généralement à 300-1000, selon les extensions et la base de code. Observe les valeurs RSS/PSS des processus : Si elles augmentent de manière significative, réduis la valeur. Comme l'OPcache divisé est, le bytecode est conservé lors du Worker-Recycling ; la plupart des apps ne ressentent donc guère le recyclage.

[www]
; recyclage ciblé sans redémarrages trop fréquents
pm.max_requests = 800

Ceux qui sont régulièrement Déploiements bénéficie d'un rechargement de la piscine. J'utilise de préférence un rechargement gracieux via le gestionnaire de services (par ex. „systemctl reload php-fpm“), afin que les requêtes en cours se terminent proprement et que les nouveaux workers démarrent avec une config mise à jour.

Slowlog et timeouts : visualiser les goulots d'étranglement de manière ciblée

La plupart des pics de latence se trouvent dans quelques requêtes lentes. J'active donc le Slowlog avec un seuil modéré (par exemple 2-5 s) et j'examine les traces de la pile. Je trouve ainsi les fonctions problématiques, les appels externes ou les requêtes coûteuses.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/slowlog-www.log

Pour aller avec, j'ai mis en correspondance les Timeouts du serveur web. Un timeout en amont (Nginx/Apache) trop court par rapport au max_execution_time de PHP entraîne des erreurs 502/504, même si FPM continue de fonctionner. Je garde la chaîne cohérente : Connect-, Read- et Send-Timeouts du serveur web juste au-dessus de la durée typique des requêtes PHP, mais en dessous de limites supérieures dures.

Interpréter correctement la file d'attente, le backlog et les valeurs de statut

Dans le statut FPM, je prête une attention particulière à „listen queue“ et „max listen queue“. Si ces valeurs augmentent régulièrement, la piscine est trop petite ou bloquée. Les pics de courte durée sont normaux, mais les congestions permanentes indiquent un sous-dimensionnement. Dans les environnements très encombrés, j'augmente le socket-arriéré modéré, observe la file d'attente et s'assure que les limites du noyau (par exemple somaxconn) ne sont pas le goulot d'étranglement.

Si le monitoring indique „seems busy, spawning children“ très souvent, les paramètres de réserve (Dynamic) sont trop étroits. Pour Ondemand, une proportion élevée et récurrente de démarrages à froid indique qu'il faut prolonger le délai d'attente (Idle-Timeout) ou maintenir une mémoire tampon minimale pendant la journée.

Plusieurs pools : Équité, isolement et quotas

Sur Multi-Tenant ou Partagé-Je sépare les applications dans leurs propres pools avec des limites individuelles. J'évite ainsi qu'un projet gourmand en mémoire ne supplante les autres. Pour les services critiques (par exemple les points finaux de connexion/API), je prévois des pools dédiés avec une réserve minimale fixe. Une dénomination claire („www-shop“, „www-api“, „www-cron“) et des logs séparés facilitent l'analyse et le suivi. Erreurrecherche.

Veille à ce que la somme de tous les pm.max_children sur tous les pools à la machine. En outre, je me procure Limites en aval un : DB-max_connections, Redis/Memcached-Threading et les taux d'API externes. Un pool PHP qui lance plus de requêtes simultanées que la base de données ne peut en supporter ne fait que s'acheter des files d'attente plus longues.

Apprivoiser le réchauffement de l'OPcache, le Preload et les démarrages à froid

À l'adresse suivante : Ondemand-Pour atténuer les démarrages à froid, je maintiens OPcache stable (suffisamment memory_consumption et interned_strings_buffer) et, si cela s'avère utile, de mettre Preload classes/frameworks centraux. Ainsi, le bytecode est prêt après le premier hit et les répétitions restent au chaud. De plus, un cache realpath plus grand et un autoloader structuré aident à réduire les lookups du système de fichiers. Au total, cela réduit considérablement le temps de démarrage des workers fraîchement lancés.

Interaction serveur web : coupler proprement Nginx/Apache

Je m'assure que les paramètres du serveur web et du FPM correspondent : Tampons et Timeouts doivent être symétriques, Keep-Alive ne doit pas bloquer FPM avec des connexions zombies, et le socket amont (Unix ou TCP) est configuré de manière cohérente. De nombreuses erreurs 502/504 sont dues à des read-timeouts mal définis ou à des backlogs épuisés. Les personnes qui s'adressent à FPM via TCP devraient tenir compte de la latence de la pile réseau et du risque d'erreur. semi-ouvert Garder un œil sur les connexions ; pour les déploiements locaux, je préfère généralement les sockets Unix.

Spécificités des conteneurs/VM

Dans les conteneurs, les cgroup-pas nécessairement les valeurs de l'hôte. Je dimensionne les pools explicitement pour la RAM du conteneur et je teste avec des pics de charge artificiels si les tueurs d'OOM pourraient intervenir. Une limite trop juste entraîne des arrêts brutaux. De même, le swapping est souvent indésirable dans les conteneurs - il vaut donc mieux être un peu plus conservateur avec pm.max_children planifier et donner la priorité à la mise en cache des applications.

Reconnaître le caractère CPU et E/S

J'évalue avec htop/iostat si les charges de travail sont CPU- ou liés aux entrées/sorties. Une utilisation élevée de l'unité centrale avec de faibles valeurs d'E/S indique une charge de calcul - dans ce cas, je limite les travailleurs plus près du nombre de noyaux. Des temps d'attente d'E/S élevés justifient un nombre plus important d'utilisateurs, car les temps d'attente sur la base de données, le réseau ou le système de fichiers se chevauchent. Tu reconnais la limite au fait que la latence ne diminue plus malgré des worker supplémentaires, mais que la charge augmente nettement.

Déchiffrer rapidement les modèles typiques 502/504

• 504 Gateway Timeout : Timeout du serveur web inférieur au temps d'exécution PHP ou pool bloqué (file d'attente pleine).
• 502 Bad Gateway : FPM inaccessible (socket/port), crash/redémarrage pendant la requête ou tampon trop petit.
• Spikes peu après le déploiement : OPcache froid, vérifier les optimisations de l'autoloader/composer, prévoir un échauffement.

Je corrige le journal d'erreurs du serveur web, le journal d'erreurs du FPM et la page d'état dans la même fenêtre temporelle. Cela permet de savoir si le problème est survenu avant, pendant ou après la mise à jour. selon FPM.

Métier de la mesure : saisir correctement les coûts de stockage

Pour la planification de la RAM, je ne regarde pas seulement le RSS, mais aussi le PSS (Proportional Set Size), car il répartit équitablement les pages partagées (par ex. OPcache) entre les processus. Des outils tels que smem ou pmap aident à déterminer des valeurs réalistes liées aux processus. Dans la pratique, des échantillons sous charge suffisent souvent : marquer plusieurs processus, calculer la valeur moyenne, comparer avec la valeur moyenne. Réserve multiplier - cela correspond mieux à la réalité que les valeurs théoriques des forums.

Mini-liste de contrôle pour des itérations rapides

• Saisir le profil de charge (RPS, percentile 50/95/99, parallélisme).
• Mesurer l'empreinte du processus (PSS, pas seulement RSS) et pm.max_children avec réserve.
• Sélectionner le mode correspondant au motif : Static (constant), Dynamic (changeant), Ondemand (beaucoup de ralenti).
• pm.max_requests Définir, observer la croissance des travailleurs, réajuster si nécessaire.
• Dimensionner l'OPcache et vérifier le warmup/preload pour amortir les démarrages à froid.
• Activer la page d'état et le slowlog, évaluer les messages de file d'attente et de spawn.
• Faire correspondre les timeouts du serveur web et les buffers avec les temps de FPM et d'app.
• Harmoniser les limites avec les systèmes en aval (DB, caches, API externes).
• Documenter les changements, mesurer et itérer de manière ciblée après les déploiements.

Résumé concis

Statique fournit le temps de réponse le plus régulier et convient à un trafic constant avec une RAM abondante. Dynamique équilibre la flexibilité et l'efficacité et marque des points en cas de changements de motifs. Ondemand permet d'économiser de la mémoire au repos et convient à de nombreux sites en sommeil, mais s'accompagne d'une latence de démarrage à froid. Avec un calcul propre des ressources, un monitoring et de petites itérations, tu prends des décisions fiables. Garde les processus aussi petits que nécessaire, utilise l'OPcache et choisit le mode qui correspond le mieux à tes besoins réels. Profil correspond.

Avec ces garde-fous, tu obtiendras des performances stables avec une consommation raisonnable. La configuration ne reste pas un jeu de devinettes lorsque les chiffres sont sur la table. Les petits pas produisent souvent les plus grands effets. Mesure, ajuste et documente. C'est ainsi que tes PHP-FPM-piscines de manière rapide, économique et prévisible.