PHP-FPM : rôle et réglage des processus
Auteur : Rédaction Domeny.ForSale Publié le
En bref : PHP-FPM (FastCGI Process Manager) est un gestionnaire de processus exécutant du code PHP sur le serveur. Il travaille avec le serveur web et gère des processus de travail capables de traiter des requêtes successives sans redémarrer l’interpréteur à chaque fois. Il facilite le bon fonctionnement des sites, notamment ceux qui utilisent WordPress, mais ne garantit pas à lui seul un chargement plus rapide : le code de l’application, la base de données et les ressources disponibles comptent aussi.
Comment PHP-FPM traite une requête de page
Lorsqu’un utilisateur ouvre une page nécessitant l’exécution de code PHP, la requête arrive d’abord au serveur web, par exemple Nginx ou Apache. Celui-ci transmet la tâche à PHP-FPM via FastCGI, un protocole de communication entre le serveur web et le processus qui exécute l’application. PHP-FPM attribue la requête à un processus de travail. Le résultat de l’exécution du code revient ensuite au serveur web, puis au navigateur.
Un processus de travail est un processus PHP déjà démarré et prêt à exécuter un script. Une fois la requête traitée, il reste généralement disponible pour la suivante au lieu de s’arrêter immédiatement. Cela évite le coût de démarrage d’un nouvel interpréteur à chaque requête, comme avec le CGI classique.
Par exemple, consulter une page dynamique de WordPress peut nécessiter d’exécuter du code PHP, de lire des données dans la base et de générer du HTML. PHP-FPM se charge de l’exécution de la partie PHP, et non de toutes les étapes nécessaires pour fournir la page. Le serveur web sert généralement les fichiers CSS, les images et les autres ressources statiques sans son intervention.
Ce qui distingue PHP-FPM de PHP et du serveur web
PHP est un langage et un environnement d’exécution du code ; PHP-FPM gère les processus de cet environnement. Ce n’est ni un langage distinct, ni un système de gestion de contenu, ni un remplacement de Nginx ou d’Apache. Ces éléments remplissent des fonctions différentes et peuvent fonctionner ensemble.
Nginx confie l’exécution des scripts PHP à un mécanisme externe, souvent PHP-FPM. Apache peut également utiliser PHP-FPM, mais certaines configurations emploient le module mod_php, qui exécute le code PHP au sein des processus d’Apache. Il ne faut donc pas supposer que tous les serveurs utilisant PHP fonctionnent de la même manière.
PHP-FPM ne remplace pas non plus OPcache. OPcache conserve le code PHP compilé en mémoire, ce qui limite la nécessité d’analyser et de compiler à nouveau les fichiers. PHP-FPM gère les processus, tandis qu’OPcache réduit une partie du travail qu’ils effectuent : les deux solutions peuvent se compléter.
Quand PHP-FPM est utile et ce qu’il ne résout pas
PHP-FPM permet de contrôler le nombre de processus, leur démarrage et leur recréation. Il aide ainsi à adapter l’exécution de l’application aux ressources du serveur et au nombre de requêtes simultanées. Cela ne signifie toutefois pas que son activation apporte toujours une nette accélération par rapport à toute autre méthode d’exécution de PHP correctement configurée.
Si une boutique attend longtemps le résultat d’une requête lente à la base de données, PHP-FPM ne rendra pas cette requête plus rapide à lui seul. Il ne supprimera pas non plus les délais d’une API externe ni le coût des opérations effectuées par une extension. Augmenter le nombre de processus peut même aggraver la surcharge de la base ou épuiser la mémoire.
Le cache de pages complètes joue également un rôle. Si du HTML déjà généré peut être renvoyé sans exécuter de code PHP, la requête n’occupe pas de processus PHP-FPM. Il en va autrement pour un panier, une interface d’administration ou une page personnalisée, qui peuvent nécessiter l’exécution de code.
Les principaux réglages des processus
PHP-FPM regroupe les processus en pools, c’est-à-dire en ensembles de processus de travail configurés séparément. Les pools peuvent avoir des limites différentes et fonctionner avec les droits de différents utilisateurs système, ce qui facilite la séparation des applications. Ce découpage ne constitue toutefois pas, à lui seul, une isolation de sécurité complète.
Le paramètre pm définit la manière dont les processus sont maintenus en fonctionnement :
static— maintient un nombre fixe de processus ; leur nombre est ainsi prévisible, mais ils occupent de la mémoire même lorsque le trafic est faible.dynamic— fait varier le nombre de processus dans les limites définies et conserve une réserve de processus inactifs.ondemand— démarre les processus à l’arrivée des requêtes et les arrête après une période d’inactivité ; cela réduit l’utilisation de la mémoire pendant les périodes creuses, mais impose de démarrer des processus à la reprise.
Le paramètre pm.max_children définit le nombre maximal de processus de travail d’un pool et, par conséquent, le nombre de requêtes PHP que ce pool peut exécuter simultanément. Lorsque tous les processus sont occupés, les requêtes suivantes peuvent être placées en file d’attente. Une attente trop longue ou une surcharge peut provoquer une erreur.
Par exemple, avec une limite de 10 processus, onze requêtes simultanées nécessitant PHP ne pourront pas toutes être exécutées en même temps. Cela ne signifie pas pour autant que le site est limité à 10 utilisateurs : un utilisateur n’occupe pas un processus pendant toute sa navigation, mais seulement pendant le traitement d’une requête donnée.
Comment savoir si la configuration doit être modifiée
Sur un hébergement mutualisé, le fournisseur gère généralement les réglages de PHP-FPM. Le panneau de gestion peut ne vous donner accès qu’au choix de la version de PHP et à certaines limites. Consultez la documentation ou l’assistance technique de l’hébergeur pour confirmer la disponibilité de PHP-FPM, les réglages accessibles et les limites de ressources.
Sur votre propre serveur, commencez par des mesures plutôt que par une augmentation des limites. Vérifiez si le pool atteint pm.max_children, quelle quantité de mémoire les processus consomment en charge et si le processeur et la base de données disposent encore d’une marge de capacité. Une fois correctement configuré, le journal des requêtes lentes de PHP-FPM peut aider à repérer le code dont l’exécution prend du temps.
Pour passer à la pratique, choisissez une opération lente, par exemple l’ouverture du panier, et déterminez si le délai vient de l’attente d’un processus disponible ou de l’exécution de l’application elle-même. C’est ce résultat qui permettra de justifier une modification des limites de PHP-FPM ou un travail sur le code et la base de données.
À lire aussi : Que signifie www ?
À lire aussi
