Passer de mod-php5 à php-fpm avec Apache

Cet article a été publié il y a 9 ans 5 mois 5 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Vous aurez probablement remarqué, mais le blog va un petit peu plus vite. En effet, j’en avais parlé dans le billet anniversaire du blog, une des évolutions de l’hébergement du blog consistait à accélérer un peu le traitement de PHP. Avec mon compère belge Arowan, on a fait l’expérience, pour l’instant on ne se plaint pas. Donc, je partage 😉

Faisons les présentations

FPM est un moteur d’exécution de PHP qui, comme son nom l’indique, se veut plus rapide qu’une exécution standard. Il est très adapté dans le cas d’applications web. Bien que n’importe quel serveur web supportant CGI peut en tirer partie, sa popularité tient surtout à son utilisation conjointe avec Nginx, un serveur web qui est particulièrement performant comparé à Apache. D’ailleurs, ma machine virtuelle à la maison utilise, entre autres, ces deux gaillards, installés grâce au script d’autoinstall de nicolargo.

Je décrirais ici les manipulations qui ont été faites sur une Debian Wheezy 64bit, qui ici est virtualisée dans une machine KVM (ce qui n’a aucune espèce d’importance, c’était juste pour rappeler :D). Il est théoriquement possible d’adapter pour d’autres distributions (à vérifier notamment les emplacements des fichiers de configuration). Ensuite, toutes les commandes sont présentées comme saisies directement avec le compte root, ajoutez sudo en cas de besoin.

Installation/préparation

Grâce à ce magnifique outil que représentent les dépôts et apt, une seule commande permet d’installer les deux paquets qui nous seront nécessaires :

Ensuite, pour ne pas créer de conflits, je conseille de couper les services qui seront concernés par les modifications de configuration :

Configuration de php-fpm

Personnellement j’ai choisi de faire écouter fpm sur un port réseau plutôt que sur un (ou une, je sais plus trop) socket local. J’ai donc modifié le fichier /etc/php5/fpm/pool.d/www.conf, en particulier la ligne suivante :

J’ai donc commenté l’ancienne configuration et ajouté la nouvelle. Évidemment, pensez à vérifier que le port est libre avant.

Pourquoi le réseau ? Théoriquement, le gain de vitesse serait plus élevé en passant par une socket locale, car on évite la ré-encapsulation du « trafic » PHP en passant par l’interface loopback. Mais l’utilisation du réseau permet de rester stable sur de plus grosses charges, et dans le cadre d’une infrastructure qui séparerait le traitement de PHP du serveur web pur (comme ça pourrait être le cas de la base de données), c’est de toute façon la seule solution. Je pense donc à ceux qui, contrairement à moi, voudraient faire la bascule sur une infrastructure qui accueille plus de monde que mes ~50 visiteurs par jour.

D’ailleurs, voilà le genre d’erreur sur laquelle vous pourriez tomber en cas de saturation de socket :

Note : si vous avez fait des modifications sur la configuration de PHP à l’époque de mod-php5 (dans le fichier /etc/php5/apache2/php.ini), il faudra les reporter dans le fichier /etc/php5/fpm/php.ini. Vous pourriez tenter un diff sur les deux fichiers pour vérifier les points à reporter, ou plus bourrin, écraser le « nouveau » fichier avec votre ancien. Mais là, si ça pète, je répond de rien, je n’ai pas procédé de la sorte.

Sinon FPM reprend tous les fichiers de configurations annexes de PHP (lien symbolique de conf.d vers le dossier parent), donc les extensions installées continueront théoriquement de fonctionner.

Configuration de fastcgi

CGI est une interface pour l’exécution de scripts. Pour utiliser FPM avec Apache, on a donc installé le module fastcgi. Et histoire de gagner du temps, puisque ce sera la seule méthode d’exécution de PHP pour tous les vhost, on va procéder de manière globale, directement au niveau d’Apache. Voilà ce qu’on doit entrer dans le fichier /etc/apache2/conf.d/mod_fastcgi.conf (le créer s’il n’existe pas) :

Notez bien que l’on renseigne l’adresse réseau de php-fpm. Pourquoi un fichier dans conf.d plutôt que modifier directement dans mods-available ? Pour garder la configuration d’origine en cas de souci.

Ensuite, on désactive « l’ancien » module mod-php5, et on active le nouveau mod-fastcgi, sinon, ça ne servirait à rien :

 Vraiment ne pas oublier de désactiver mod-php5, sinon c’est lui qui restera en service, avec FPM qui attendra désespérément dans le vide. Oui oui, on en a fait l’expérience 😀

Remise en service

Les services sont installés, configurés, activés, y’a plus qu’à lancer :

Étape subsidiaire : Une fois que vous avez définitivement validé la bascule, vous pouvez supprimer le paquet libapache2-mod-php5 pour être sur de ne pas le voir réactivé par accident, ce qui pourrait causer les mêmes désagréments que le passage de mod-php5 à php-fpm (en particulier si vous modifiez la configuration de php).

Conclusion

Let the magic begins 🙂 Personnellement, je n’ai pas fait de vérifications chiffrées de l’amélioration de performances, mais vu comment Piwik fuse, j’aurais tendance à dire que ça répond bien. La consommation mémoire est un peu plus élevée, mais rien de mortel non plus. La génération des miniatures d’images dans WordPress est plus rapide aussi (moins d’attente après l’upload). Bref, c’est du bon.

Pour la sortie d’Apache 2.4, le wiki propose une méthode légèrement différente. Je ne sais pas s’il faut la recommander aux utilisateurs d’Ubuntu qui y ont accès. De toute façon, cette installation d’FPM n’est qu’une première étape d’une migration prévue vers Nginx. Comprenez donc que je ne me sens pas plus concerné que ça.