Faut-il utiliser PHP-FPM ?

Après mon article qui encourage les gens à reconsidérer calmement Apache, je voulais dire un mot de la pertinence ou non d’utiliser php-fpm. Performant ; il l’est sans doute. Ce n’est pas son principal avantage à mes yeux. Mais il n’est pas sans défaut, et complexifie sérieusement la tuyauterie.

Voici mon analyse. (Je me place dans le contexte Apache mais tout ce que je dis est valable pour Nginx.)

Qu’est ce que php-fpm ?

PHP-FPM signifie PHP FastCGI Process Manager ; il est donc intimement lié à Apache via mod_fastcgi, mod_fcgid ou encore mod_proxy_fcgi. (Je ne veux pas être trop technique dans ce billet donc je reviendrai sur l’un ou l’autre prochainement.)

Là ou par défaut Apache exécute le PHP via l’inclusion “permanente” de mod_php ; ici vous n’avez plus d’interpréteur php “chargé” directement avec apache dans chaque process ; au contraire vous chargez l’un des “mods” que j’ai cité de “gérer” le PHP qui est envoyé tel quel à un processus externe ( php-fpm ) qui dispose de sa propre configuration.

Vous avez donc, déjà à ce stade, plusieurs outils à configurer ;

  1. Apache , qui doit charger mod_fastcgi,
  2. la config de mod_fastcgi lui même (qui est simple mais pas sans surprise),
  3. et celle de php-fpm (qui est complexe)
  4. Ajoutez également une configuration de PHP.

Avantages de php-fpm

Pourquoi ne plus utiliser mod_php  ? Vous lirez de nombreuses raisons ayant trait à la performance sur le web, et sincèrement je ne compte même pas en parler. En effet je n’ai pas réalisé moi même ce type d’analyse. Vous lirez tout ca chez de nombreux experts auto proclamés 🙂 Disons que “le web” nous dit que php_fpm est plus “performant”, donc gardons cela dans un coin de l’esprit. Egalement, la “performance” est quand même toute relative ; votre applicatif est-il performant également ?

Un des avantages réels de php_fpm est au niveau de la sécurité ; vous pouvez faire en sorte que votre interpréteur php ; et donc tout ce que php créera ou lira, soit executé sous un user précis ( et non plus sous www-data ou httpd ). Ceci équivaut si vous voulez à avoir un su_php intégré dans mod_php. Vous pouvez segmenter correctement vos utilisateurs, lier cela à leurs permissions FTP et Unix par exemple. Fini d’avoir les scripts d’un vhost qui lisent le code d’un autre vhost.

D’autre part vous pouvez lancer ce qu’on appelle un “pool” d’interpreteurs PHP pour chacun de vos clients, ou de vos vhosts. Ceci présente un autre avantage; vous pouvez décider que tel pool dispose de plus de ressources qu’un autre, fixer des limites d’utilisation parallèles à chacun, et même “re nicer” les process de tel ou tel pool ; en clair faire que le php de certains clients s’execute plus rapidement que celui d’autres. Ce qui est une façon polie de dire que le PHP de certains clients ne foute pas tout le serveur par terre.

Enfin, dernier avantage ; vous pouvez avoir plusieurs versions de PHP sur le même serveur. Ce n’est pas une configuration que j’irais recommander, mais c’est possible et utile. Ainsi certains clients sont en PHP5.3, d’autres en 5.6, et tout ce petit monde cohabite dans votre unique processus “Apache port 80” qui lui, en fait, ne sait même pas ce que PHP veut dire.

Inconvénients de PHP-FPM

Formidable ! Vendu ! Adieu mod_php ! Et bien pas toujours. Et même en fait, pas si souvent.

Si on reprend tous mes arguments, vous verrez que le ver est dans le fruit ; php-fpm est un process dédié à l’éxecution de PHP dès que Apache le demande, et c’est dans cet aspect “permanent” que se cachent les soucis. En effet, le web croule littéralement sous les problèmes de php_fpm, d’affreuses erreurs 503, bad gateway, etc. Avoir pour travail de compiler du PHP, si possible en restant tout le temps chargé et en enfilant les demandes de compilation de PHP est un boulot dangereux. Compiler du PHP semble être devenu tellement complexe que le process peut être “endommagé”, grossir, planter à cause du code qu’il execute sans cesse.

Là ou avec mod_php vous ne plantiez pas grand chose d’autre que le surfeur qui a fait le demande pourrie, avec un interpreteur “pourri” lui aussi et qui disparaitra aussi vite que le gars fait “stop” ou après un timeout très court (puisqu’il est lié à Apache donc à la session); ici (par défaut) vous avez des interpreteurs php professionnels qui “accumulent les déchets” s’il y en a souvent.

Ainsi, php-fpm est un des rares logiciels qui possède une option pour se relancer lui-même après X compilations ; autrement dit ils admettent eux mêmes dans leurs propre configuration qu’il peut être utile de “flinguer” le fpm-php a intervalles régulier pour lui vider un peu la tête. La deja ca commence à sentir mauvais.

D’autre part, si on pousse le raisonnement au ridicule, le fonctionnement le plus “safe” de php-fpm serait donc un process qui se recycle rapidement, pourquoi pas après chaque compilation tant qu’a faire ; et qui spawne “dynamiquement”. Super, on a ré inventé mod_php en plus lent. Je caricature  ; je comprends bien que l’interpreteur ne va pas merder à chaque compilation, mais admettez que c’est la logique dans laquelle nous poussent des options de ce genre.

Enfin, niveau sécurité, php_fpm (en particulier proxy_fcgi) pose ses propres problèmes. Certaines attaques sont directement liées à ce mode d’execution (ca nous mènerait un peu loin) et donc vous ajoutez de nouvelles vulnérabilités en en supprimant d’autres. Le bilan n’est donc pas parfait, c’est une balance à trouver suivant chaque cas. Si votre serveur ne fait qu’executer votre propre code, pas d’autres users, vous ajoutez “en net” des vulnérabilités. J’ajouterais que php_fpm est particulièrement sujet à l’épuisement de ressources suivant la qualité de sa configuration, ce qui est quand même un comble pour un système performant.

Conclusion ?

Si on parle d’un serveur shared, avec des clients, qui ont tendance a écrire du code douteux ; php-fpm écrase littéralement mod_php , et même si on peut obtenir les fonctions de php_fpm en truffant de mods supplémentaires ; autant aller au plus simple.

Si on parle d’un serveur sur lequel vous êtes seul et qui doit être performant ; l’absence de qualité de la configuration de php-fpm peut faire que vous vous donniez du mal à produire un “bidule” compliqué qui sera moins stable que mod_php. En clair configurer php_fpm est nettement plus complexe et surtout peut produire des setups qui sont bien moins résiliants qu’un “bête” mod_php.

Enfin, la notion même de process “qui fait le php” est une faiblesse en soi, utilisée par certaines attaques. Si la sécurité est une priorité, rien ne vaut un reverse proxying.

J’espère en tout cas vous avoir bien introduit à php-fpm 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *