Qu’est-ce que PHP-FPM | Installer et configurer PHP-FPM

Environnement de test Famille RHELAlmaLinux 9.8Apache 2.4 + PHP-FPM 8.3Compte rootVérifié le 2026-10-26

PHP-FPM est un gestionnaire de processus FastCGI : des processus worker lancés à l'avance reçoivent les requêtes PHP que leur transmet un serveur web et les traitent. Sur un serveur AlmaLinux 9 qui fait tourner Apache, ce guide vérifie si PHP-FPM est installé et comment sont réglés les pools et les sockets de chaque site, puis va jusqu'au test de la configuration et à la vérification de l'état, avec les sorties réelles.

Apache peut aussi exécuter PHP directement avec mod_php, mais si vous le confiez à PHP-FPM, le serveur web et PHP sont séparés. Nginx ne peut pas exécuter PHP directement : il transmet les requêtes à un processus FastCGI comme PHP-FPM. C'est pourquoi un seul PHP-FPM peut être relié aussi bien à Apache qu'à Nginx. La configuration des pools et la structure des sockets ci-dessous s'appliquent telles quelles quand vous reliez PHP-FPM à Nginx.

Sommaire

4 min de lecture

1️⃣ Qu'est-ce que PHP-FPM : la différence entre CGI et FastCGI

CGI (Common Gateway Interface) est la méthode standard par laquelle un serveur web exécute un programme externe pour produire du contenu dynamique, et il relance le programme à chaque requête reçue. Le coût de création et de suppression d'un processus à chaque requête s'accumule, et le serveur répond de plus en plus lentement à mesure que les accès augmentent.

FastCGI supprime ce coût en lançant le programme à l'avance et en traitant les requêtes les unes après les autres. C'est la différence entre allumer et éteindre un ordinateur à chaque utilisation et utiliser directement un ordinateur déjà allumé. PHP-FPM (FastCGI Process Manager) est le gestionnaire qui fait fonctionner PHP via FastCGI, et il est inclus dans PHP depuis la version 5.3.3.

Pour chaque pool, c'est-à-dire un groupe de workers, PHP-FPM lance à l'avance le nombre de workers fixé ; un worker libre reçoit la requête que le serveur web lui transmet par le socket, la traite, puis attend la suivante. Les fichiers statiques comme les images et le CSS sont servis directement par le serveur web, et seuls les fichiers PHP sont transmis à PHP-FPM. Seule la façon dont le serveur web transmet les requêtes au socket change : Apache utilise le module mod_proxy_fcgi et Nginx utilise la directive fastcgi_pass.

🧩 Comment CGI et PHP-FPM traitent les requêtes

Schéma explicatif

⚙️ Exécution de PHP

🌐 Serveur web

🌐 ApacheNginx

📨 Requête 1 · index.php📨 Requête 2 · wp-login.php📨 Requête 3 · index.php

Les fichiers statiques (images, CSS) sont servis directement par le serveur web

Exécuté à chaque requêteFastCGI · socket→

🧱 Processus CGI

Requête 1Nouveau processus → traitement → arrêt

Requête 2Nouveau processus → traitement → arrêt

Requête 3Nouveau processus → traitement → arrêt

Une fois le traitement terminé, le processus disparaît · la requête suivante repart de zéro

🧰 Pool PHP-FPM [siteuser]

Worker 1Requête 1

Worker 2Requête 2

Worker 3Requête 3

Worker 4attente

Worker 5attente

Les workers lancés à l'avance reçoivent les requêtes puis attendent la suivante

Quand Apache exécute PHP en CGI, il lance un nouveau processus PHP à chaque requête et l'arrête à la fin du traitement, si bien que le coût de création des processus s'accumule à mesure que les requêtes augmentent.

Nginx n'a aucun module qui exécute directement des programmes CGI, donc cette combinaison n'est pas utilisée ; PHP est transmis à PHP-FPM via FastCGI.

Apache transmet les requêtes PHP au socket avec mod_proxy_fcgi, et un worker PHP-FPM lancé à l'avance la reçoit, la traite, puis attend la suivante.

Nginx les transmet au même socket avec fastcgi_pass, donc même avec un autre serveur web, le pool PHP-FPM reste le même.

2️⃣ Installer PHP-FPM : vérifier le paquet et installer avec dnf

Si vous avez installé PHP avec dnf sur un serveur de la famille RHEL, le paquet php-fpm a été installé en même temps. Vérifiez d'abord avec rpm s'il est installé. Le processus d'installation de PHP est le même que dans Installer APM sur Rocky Linux.

rpm -qa | grep php-fpm

php-fpm-8.3.36-1.module_php.8.3.el9.remi.x86_64

Si la sortie est vide, il n'est pas installé ; installez-le avec dnf.

dnf -y install php-fpm

Une fois l'installation terminée, relancez la même commande rpm pour vérifier que le nom du paquet s'affiche.

3️⃣ Configurer PHP-FPM : le pool www.conf, le socket et les modes statique et dynamique

Il y a deux fichiers de configuration : la configuration générale [/etc/php-fpm.conf] et la configuration des pools [/etc/php-fpm.d/www.conf]. Les lignes à regarder en premier dans le pool par défaut www.conf sont listen et pm, et leurs valeurs juste après l'installation sont les suivantes.

grep -E '^(listen|pm) ' /etc/php-fpm.d/www.conf

listen = /run/php-fpm/www.sock
pm = dynamic

listen est l'endroit où le serveur web transmet les requêtes, et la valeur par défaut de la version 8.3 est le socket Unix [/run/php-fpm/www.sock]. La valeur par défaut des anciennes versions, [127.0.0.1:9000], reçoit les requêtes sur un port TCP. À l'intérieur d'un même serveur, le socket est plus léger car il évite l'étape de connexion par port, et listen.owner et listen.group permettent de restreindre l'accès comme avec des droits de fichier.

🔲 Configurer le mode statique et le mode dynamique

pm est la façon de lancer les workers, et vous le réglez sur l'une de ces trois valeurs : static, dynamic ou ondemand. Le mode statique garde toujours lancé le nombre indiqué dans pm.max_children, et le réglage ci-dessous maintient 100 workers.

pm = static
pm.max_children = 100

Le mode dynamique est le mode par défaut et fait monter ou descendre le nombre de workers selon le volume de requêtes. Le réglage ci-dessous en lance 12 au démarrage, garde entre 6 et 18 workers libres et monte jusqu'à 120 au maximum.

pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18

Le mode ondemand ne lance des workers que lorsqu'une requête arrive et les arrête une fois pm.process_idle_timeout écoulé ; il convient donc aux sites peu fréquentés et ne convient pas aux sites très fréquentés.

Les trois modes se distinguent par le moment où ils lancent les workers et par la façon dont leur nombre monte ou descend.

Mode	Façon de lancer les workers	Sites adaptés
static (statique)	Garde toujours lancé le nombre indiqué dans pm.max_children	Sites très fréquentés
dynamic (dynamique)	Par défaut · monte ou descend dans les limites de pm.start_servers, pm.min_spare_servers et pm.max_spare_servers selon le volume de requêtes	Sites dont la fréquentation monte et descend
ondemand	Ne lance des workers que lorsqu'une requête arrive et les arrête une fois pm.process_idle_timeout écoulé	Sites peu fréquentés

max_children se fixe en divisant la mémoire du serveur par la mémoire qu'utilise un worker. Même quand les avertissements sur [max_children] s'accumulent, ne le relevez pas tout de suite ; commencez par repérer dans les logs quelles requêtes ont rempli les workers.

La mémoire et la limite d'envoi se règlent dans php.ini, la configuration générale de PHP, et s'ajustent avec le nombre de workers en fonction du site que vous exploitez.

memory_limit = 1024M
post_max_size = 128M
upload_max_filesize = 128M

Ces trois valeurs sont la limite de mémoire qu'un script PHP peut utiliser et la taille des fichiers que l'on peut envoyer en une fois, et elles ne s'appliquent qu'après un redémarrage de PHP-FPM.

🔲 Configurer un pool par compte de site

Quand il y a plusieurs sites, on ne partage pas un seul www.conf : on crée un fichier de pool par compte et l'on sépare le compte d'exécution et le socket. Le PHP d'un site ne peut pas lire les fichiers d'un autre compte, et le nombre de workers est fixé site par site.

vi /etc/php-fpm.d/siteuser.conf

Le fichier indique le nom du pool, le compte d'exécution, le chemin du socket et le nombre de workers.

[siteuser]
user = siteuser
group = nobody
listen = /run/php-fpm/siteuser.sock
listen.owner = siteuser
listen.group = nobody
listen.mode = 0660
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
chdir = /home/siteuser/www

listen.owner et listen.group sont le propriétaire et le groupe du fichier du socket, et PHP-FPM crée le socket avec ces valeurs au démarrage. Si le serveur web s'exécute avec le compte nobody, indiquez nobody dans listen.group ; avec le compte apache, indiquez apache, afin que le serveur web puisse ouvrir le socket.

listen.owner = siteuser
listen.group = nobody
listen.mode = 0660

Ces trois lignes figurent dans chaque fichier de pool, et après avoir modifié les valeurs, il faut redémarrer pour que le socket soit recréé avec les nouveaux droits.

🔲 Configurer slowlog

slowlog est un fichier qui enregistre l'endroit où s'exécutait une requête ayant duré plus que request_slowlog_timeout, et une valeur de 0 signifie qu'il n'enregistre rien. Quand vous cherchez la cause des requêtes lentes, activez-le en indiquant une durée en secondes, comme 3s.

slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 0

Le fichier enregistré conserve le chemin du script de la requête lente et la fonction en cours d'exécution à ce moment-là, ce qui permet de voir quel plugin ou quel code a pris du temps.

4️⃣ Intégration avec Apache : configuration du VirtualHost et droits du socket

Apache transmet les requêtes de fichiers PHP au socket du pool avec le module mod_proxy_fcgi. Vous placez une ligne SetHandler dans le FilesMatch du VirtualHost, et vous indiquez pour chaque site le socket de son compte.

# Un VirtualHost par compte de site · SetHandler reçoit le socket de ce compte (on peut aussi relier avec ProxyPassMatch à la place de SetHandler)
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /home/siteuser/www

    <Directory /home/siteuser/www>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php-fpm/siteuser.sock|fcgi://localhost"
    </FilesMatch>
</VirtualHost>

DocumentRoot et Directory sont la racine web de ce compte, et -Indexes dans Options empêche la liste des dossiers d'être affichée dans le navigateur.

🔲 Configurer les droits du socket

Au démarrage du pool, le socket est créé avec les valeurs de listen.owner, listen.group et listen.mode, et vous vérifiez avec ls que les droits sont corrects.

ls -l /run/php-fpm/

total 4
srw-rw----  1 siteuser_a nobody 0 oct. 22 23:34 siteuser_a.sock
-rw-r--r--  1 root       root   7 oct. 26 03:00 php-fpm.pid
srw-rw----  1 siteuser_b nobody 0 oct. 22 23:34 siteuser_b.sock
srw-rw----+ 1 root       root   0 oct. 22 23:34 www.sock

Si les droits ne correspondent pas et que le serveur web ne peut pas ouvrir le socket, les visiteurs reçoivent une erreur 503 ; pour corriger tout de suite sans redémarrer, indiquez le propriétaire et les droits avec chown et chmod.

Syntaxe actuelle (deux-points)
Ancienne syntaxe (point)

C'est la syntaxe actuelle, qui sépare l'utilisateur et le groupe par deux-points.

chown siteuser:nobody /run/php-fpm/siteuser.sock

Après avoir changé le propriétaire, réglez les droits sur 660.

chmod 660 /run/php-fpm/siteuser.sock

C'est l'ancienne syntaxe, qui sépare l'utilisateur et le groupe par un point, et chown l'exécute encore telle quelle sur AlmaLinux 9.

chown siteuser.nobody /run/php-fpm/siteuser.sock

Après avoir changé le propriétaire, réglez les droits sur 660.

chmod 660 /run/php-fpm/siteuser.sock

Le résultat des deux syntaxes est le même : quelle que soit celle que vous utilisez, le propriétaire du socket devient siteuser et son groupe devient nobody.

🔲 Intégration avec Nginx : la directive fastcgi_pass

Dans Nginx, le location des fichiers PHP à l'intérieur du bloc server transmet les requêtes au socket du même pool avec fastcgi_pass.

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php-fpm/siteuser.sock;
}

Si Nginx s'exécute avec le compte nginx, il faut indiquer nginx dans listen.group du fichier de pool pour qu'il puisse ouvrir le socket.

5️⃣ Test de la configuration et redémarrage : php-fpm -t et systemctl

Après avoir modifié la configuration, ne redémarrez pas tout de suite ; faites d'abord une vérification de syntaxe avec php-fpm -t. Si un fichier de pool contient une faute de frappe, tout PHP-FPM tombe au redémarrage et tous les sites reçoivent une erreur 503.

php-fpm -t

[26-Oct-2026 17:33:45] NOTICE: configuration file /etc/php-fpm.conf test is successful

Si la vérification réussit, le message [test is successful] s'affiche avec le chemin du fichier de configuration, puis vous appliquez le changement à PHP-FPM. Un changement qui oblige à recréer le socket, comme le chemin du socket ou listen.owner, s'applique avec restart. Si vous n'avez changé que des valeurs comme le nombre de workers sur un serveur en production, appliquez-le avec reload.

systemctl restart php-fpm

Si vous avez modifié le VirtualHost, redémarrez aussi Apache.

systemctl restart httpd

Enregistrez-le avec enable pour qu'il s'exécute automatiquement quand le serveur est rallumé.

systemctl enable php-fpm

Vérifiez s'il est enregistré avec is-enabled.

systemctl is-enabled php-fpm

enabled

Avec status, vérifiez que des workers tournent pour chaque pool.

systemctl status php-fpm

● php-fpm.service - The PHP FastCGI Process Manager
     Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; preset: disabled)
     Active: active (running) since x
    Process: 3934033 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, status=0/SUCCESS)
   Main PID: 1333314 (php-fpm)
     Status: "Processes active: 4, idle: 21, Requests: x, slow: 0, Traffic: x"
      Tasks: x
     Memory: x
        CPU: x
     CGroup: /system.slice/php-fpm.service
             ├─  41920 "php-fpm: pool siteuser_a"
             ├─  94143 "php-fpm: pool siteuser_b"
             ├─1333314 "php-fpm: master process (/etc/php-fpm.conf)"
             ├─3934078 "php-fpm: pool www"
             └─4009016 "php-fpm: pool siteuser_a"

oct. 26 03:00:01 server.example.com systemd[1]: Reloading The PHP FastCGI Process Manager...
oct. 26 03:00:01 server.example.com systemd[1]: Reloaded The PHP FastCGI Process Manager.

Dans la ligne Status, active et idle sont les workers qui traitent des requêtes à cet instant et les workers libres, et CGroup énumère les workers par nom de pool. Le nom d'hôte et les noms de pools de la sortie ont été remplacés par des valeurs d'exemple.

🔢 FAQ & contenus recommandés

mod_php exécute PHP à l'intérieur du processus Apache, donc la configuration est simple, mais PHP est chargé dans chaque worker Apache, ce qui consomme beaucoup de mémoire et rend difficile de séparer le compte d'exécution site par site. PHP-FPM sépare PHP dans des processus à part, si bien que chaque site peut avoir son propre compte et son propre nombre de workers ; sur un serveur avec plusieurs sites ou qui utilise Nginx, on utilise donc PHP-FPM.

systemctl reload php-fpm envoie un signal USR2 au processus maître, qui relit la configuration et remplace les workers. Si vous définissez process_control_timeout, les workers qui ont terminé la requête en cours sont remplacés en premier (selon la documentation officielle). restart arrête tous les workers puis les relance d'un coup, de sorte que les requêtes en cours à cet instant peuvent être coupées ; sur un serveur en production, utilisez donc reload en premier.

Sur la famille RHEL, le journal par défaut est [/var/log/php-fpm/error.log], et les avertissements de manque de workers (seems busy · max_children) ainsi que les enregistrements de démarrage et d'arrêt des pools y sont conservés. Dans le fichier que vous indiquez pour un pool avec php_admin_value[error_log], les erreurs du code PHP de ce site sont enregistrées à part. Le pool par défaut écrit dans [/var/log/php-fpm/www-error.log].

🔗 Articles recommandés

Étape suivante Comparatif des hébergements WordPress : le top 7 de 2026 Un article qui compare les tarifs et les scores de vitesse de 7 hébergeurs, pour le cas où vous confiez les pools PHP-FPM et la configuration du serveur web à un hébergement géré au lieu de les exploiter vous-même. Lire l'article →

Arborescence des domaines où la mise en cache est utilisée

Cache Cache : définition et tous les domaines où la mise en cache est utilisée Explique, domaine par domaine, comment les requêtes qui trouvent leur réponse dans le cache n'arrivent jamais jusqu'à un worker PHP-FPM.

Serveur de cache Installer et configurer Varnish Cache avec Apache et Nginx Les étapes d'installation pour placer un serveur de cache devant le serveur web et réduire ainsi les requêtes PHP elles-mêmes.

Tableau des commandes Linux par catégorie

Linux Les 15 catégories de commandes Linux Un tableau qui classe les commandes en 15 catégories, dont rpm, grep et systemctl utilisées dans cet article.

🪐RéférencesPHP-FPM 5

📡Documentation de Rocky Linux : PHP et PHP-FPM (en coréen) 📡Rocky Linux Docs: Apache Integration 📡Apache HTTP Server: mod_proxy_fcgi 📡PHP Manual: FPM Configuration 📡nginx: ngx_http_fastcgi_module

ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur^{(il baisse lors des promotions ↓)}, lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.