Optimiser PHP-FPM

Bloqueur de pub détectée - Vous bloquez l'affichage des publicités.
Pour soutenir le site, merci de bien vouloir laisser les publicités s'afficher.

Plus d'informations : Comment désactiver les bloqueurs de publicité sur un site internet.

PHP-FPM est un serveur PHP que l'on utilise souvent avec nginx afin de délivrer du contenu PHP.

Par défaut, la configuration de PHP-FPM n'est pas top surtout si vous avez un site avec pas mal de trafic.

Cet article vous présente les paramètres à modifier afin d'optimiser PHP-FPM.

Optimiser PHP-FPM

Introduction

PHP-FPM est un serveur PHP que l'on peut utiliser avec Nginx ou Apache.
Ce dernier agit en tant que proxy pour se connecter au serveur PHP afin de retourner les pages WEB au navigateur WEB.

Le schéma ci-dessous récapitule le process.

Image credit: ProinerTech

PHP-FPM fonctionne avec des processus que l'on peut configurer.
Un peu comme sur Apache avec le nombre de clients.

Lorsque le nombre de processus est trop petit, le serveur ne pourra répondre à la demande.
En général, cela se traduit par des erreurs de type Connection reset by peer dans les logs.
En effet la connexion de Nginx ou Apache vers PHP-FPM ne se fait pas car ce dernier ne parvient pas à répondre.

Nginx et Connection reset by peer vers PHP-FPM

Du côté de l'internaute, on assiste à des latences et parfois des erreurs HTTP.
Une bonne configuration permet de délivrer les pages rapidement et éviter de mauvaises expériences.

Optimiser les paramètres pm

La configuration de PHP-FPM se fait depuis le fichier www.conf.
Par exemple sur une Debian, on trouve ces deux fichiers :

  • /etc/php/7.3/fpm/php-fpm.conf.
  • et une autre partie dans /etc/php/7.3/fpm/pool.d/www.conf

Bien sûr selon la distribution Linux ou si vous utilisez Windows, le fichier de configuration aura un autre emplacement.

C'est ce dernier qui nous intéresse.
Les paramètres pm sont les plus importants et régit le fonctionnement du serveur PHP.

Que sont les paramètres PM ?

Tout d'abord le paramètre pm propose trois modes de fonctionnement.

  • demand : Les processus sont créés et supprimés à la demande.
  • dynamic : On fixe un nombre minimale et maximale de processus que PHP-FPM va garder en vie.
  • static : Un nombre fixe de processus est gardé quoiqu'il arrive.

Ces paramètres sont rangés du moins performant au plus performant.
En effet, les va et vient incessant qui nécessite de créer des processus réduit les performances.
Par contre, le dernier paramètre consomme plus de ressources.
En effet les processus PHP restent toujours ouverts.

Voici ensuite les paramètres que l'on peut régler pour le cas du dynamic et static.

  • pm.max_children: Le nombre maximum de processus enfant
  • pm.max_requests: Le nombre de requête par processus avant de ressusciter.
  • pm.min_spare_servers: Le nombre minimum de processus serveur inactifs
  • pm.max_spare_servers: Le nombre maximum de processus serveur inactifs
  • pm.process_idle_timeout: Le temps avant qu'un processus inactifs soient tués.
PHP-FPM et les paramètres pm.

Par exemple le nombre de processus inactifs doit être suffisants afin d'éviter de devoir en créer.
Cela fait perdre du temps et selon comment peut faire que le serveur ne répond plus.
Il ne sert pas non plus à créer trop de serveurs inactifs car ils vont consommer de la mémoire pour rien.
En clair donc, il faut trouver un équilibre entre votre trafic et les ressources systèmes.

Par défaut, sur Debian, PHP-FPM est réglé en mode dynamique.
Toutefois sur les sites qui ont un peu de trafic, les réglages sont trop petits.
Ainsi on arrive à un message : server reached pm.max_children settings. Consider raising it.
Les conséquences évoquées plus haut comme des latences ou erreur 502 arrivent alors régulièrement.
Ce dernier indique d'augmenter le nombre maximum de processus enfant.

PHP-FPM : server reached pm.max_children settings. Consider raising it.

Les bon réglages

On conseille donc de régler le serveur en static pour de meilleurs performances surtout si vous avez du trafic.
En effet pour les petits sites le gain ne se verra pas beaucoup car il n'y a pas beaucoup de fluctuation.
Par contre, si vous avez de grosses fluctuations de trafic, le mode dynamic risque de poser des problèmes.

Enfin le mode static demande plus de ressources systèmes.

Les paramètres se font ensuite selon le volume de trafic.
Voici un ordre d'idée.

TraficMoyenImportant
Max Children100500
Process Idle Timeout100150
Max Requests3002000

Bien entendu, vous pouvez partir du plus petit et monter au fur et à mesures afin de tester.

D'autre part, vous pouvez calculer le nombre maximum de processus PHP-FPM.
Pour cela, on utilise la commande top :

top -bn1 | grep php-fpm

Prenez en compte la 7e colonne qui correspond au RES, soit la mémoire privée du processus.
On voit que la moyenne est à 100k.
Ainsi vous pouvez calculer la consommation mémoire totale selon le nombre de processus.

Lister les processus php-fpm en cours de fonctionnement

Enfin PHP-FPM propose une page de status qui permet aussi d'obtenir des informations.

Activer la page de status

On peut activer les pages de status en décommettant la valeur pm.status_path.

Activer la page de status

Ensuite on créé le site qui va bien dans nginx.
Par exemple comme ceci.
Bien sûr, vous devez modifier selon votre configuration surtout par rapport au fastcgi_pass.

server {
#### STATUS...
        server_name localhost;
        server_name 127.0.0.1;
        access_log off;

        location /nginx_status {
                stub_status on;
                allow 127.0.0.1;
                deny all;
        }

        location ~ ^/(status|ping)$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
            fastcgi_pass   unix:/run/php/php7.3-fpm.sock;
             allow 127.0.0.1;
             deny all;
        }
}
Activer la page de status

On peut alors accéder au site avec l'URL : http://127.0.0.1/status.
Ce qui donne ceci.

status php-fpm pour obtenir des informations

Ce qui donne les informations suivantes :

  • pool - le nom de la piscine
  • process manager - statique, dynamique ou à la demande
  • start time - la date et l'heure auxquelles FPM a commencé
  • start since - nombre de secondes écoulées depuis le début de FPM
  • accepted conn - le nombre de demandes acceptées par le pool
  • listen queue - nombre de demandes dans la file d'attente des connexions en attente
  • max listen queue - nombre maximal de demandes dans la file d'attente de connexions en attente depuis le démarrage de FPM
  • listen queue len - taille de la file d'attente des connexions en attente
  • idle process- nombre de processus inactifs
  • active processes - nombre de processus actifs
  • total process - nombre de processus inactifs + processus actifs
  • max actives processes - nombre maximal de processus actifs depuis le démarrage de FPM
  • max children reached - nombre de fois que la limite de processus a été atteinte, lorsque pm tente de démarrer plus d'enfants (fonctionne uniquement pour pm ‘dynamic’ et ‘ondemand’)
  • requêtes lentes - nombre de requêtes dépassant votre valeur request_slowlog_timeout

Ainsi ici on voit que l'on a beaucoup de processus en idle.
Le maximum de processus actif est 41.
On doit donc pouvoir réduire le nombre de processus.
Toutefois le serveur n'est pas encore saturée au niveau de la mémoire comme le montre top.

Consommation mémoire php-fpm

Activer les plugins PHP-FPM pour Munin

Enfin Munin peut grapher des infos PHP-FPM afin de suivre dans le temps.
Cela permet aussi d'obtenir des infos supplémentaires.
Pour se faire, il faut ajouter des plugins sur Munin.
Cela n'a rien de compliqué.
Deux projets github existent :

Ces derniers nécessitent l'activation de la page status de PHP-FPM.

Ci-dessous les connexions PHP-FPM avec leurs états.
Le second graph est très important.
En effet, il donne le nombre de processus max avec le nombre d'actif et donc idle.
Il ne faut pas que le nombre de processus actif se rapproche trop du nombre max total.
Sinon vous aurez des problèmes de performance.

PHP-FPM en graphique sur Munin

L'âge des processus avant que ces derniers soit tués quand il dépasse le délai max d'inactivité (idle).
On trouve aussi l'utilisation mémoire moyenne.
Ce dernier graph permet donc de calculer le nombre de maximum de processus que l'on peut lancer.

PHP-FPM en graphique sur Munin

Enfin la CPU utilisée par PHP-FPM et le nombre de processus.
On retrouve ici la configuration pm.max_children.

PHP-FPM en graphique sur Munin

Les slowlog

Enfin les slowlog enregistrent les requêtes lentes.
Cela permet donc de connaître les pages lentes de votre site ou déceler des anomalies.

Vous pouvez activer ces derniers.

Pour cela, on active le paramètre slowlog avec le chemin du fichier journal.
Le délai d'écriture avec le paramètre request_slowlog_timeout.

Les slowlog de PHP-FPM

Enfin on relance php-fpm avec service php-fpm restart.

Les slowlog de PHP-FPM
Vous avez trouvé cet article utile et interressant, n'hésitez pas à le partager...

Trouver la solution sur le forum d'aide

Vous êtes arrivé au terme de l'article Optimiser PHP-FPM mais vous n'avez pas trouvé la solution à votre problème...
Suivez ces articles du forum pour trouver une réponse ou demandez à votre tour de l'aide sur le forum