On peut lire un peu partout, et par exemple sur le présent blog, que le couple Apache MPM Worker / PHP-FPM représente un gain de performance, sécurité, souplesse jamais égalés. Et cela est tout à fait exact. Mais alors, NBS, pourquoi diable n’est-ce pas là la solution déployée par défaut sur vos serveurs ?

Pour comprendre la réponse à cette angoissante question, il faut avant tout savoir que mod_php en mode shared object n’est pas disponible pour un Apache en mode MPM, ni sous Debian, ni ailleurs. Par conséquent, lorsqu’on choisit le mode Multi-process + multithread d’Apache, nous sommes contraints d’utiliser un module de type FastCGI, le plus performant à l’heure actuelle étant PHP-FPM

Jusqu’ici, rien ne semble contre-indiquer ce choix. Les modules de type FastCGI on cette faculté de grandement soulager Apache, et pour cause, plutot que d’embarquer l’interpréteur dans le serveur HTTP, un système de communication (socket locale ou TCP pour les plus performants) permet au serveur de demander à un programme tiers l’interprétation d’un code. Ceci est d’autant plus puissant que l’interpréteur peut par exemple se placer sur une machine tierce lorsque la communication s’effectue à travers IP.

Mais alors qu’attendons nous !

Alors que l’excitation de la performance est à son apogée, deux éléments perturbateurs viennent jouer les trouble fête.

Premièrement, notre vieil ami le .htaccess. En effet, nombre de nos partenaires utilisent la possibilité qu’offre le htaccess de communiquer avec PHP pour fournir des paramêtres particuliers tels que le fâmeux php memory_limit. En passant en mode FastCGI, plus question d’une telle souplesse, ce sera le fichier de configuration php.ini qui devra être manipulé, impactant ainsi l’ensemble des sites PHP hébergés. Inconcevable.

Deuxièmement, notre vieil ami Magento (mais probablement d’autres produits PHP du même acabit). Nous vous entretenions ici-même il y a quelques semaines des bugs inhérents à Magento, connus mais non corrigés, quand à son interprétation en mode CGI. Cette petite mésaventure ne donne guère confiance quand à la parfaite adhérence entre le produit et une implémentation « originale » du couple Apache/PHP, et pourrait aboutir à une vague de suicides dans le milieu du developpement PHP, ce qui serait peu souhaitable pour la bonne santé de notre entreprise.

Forts de ce constat, nous continuons donc à déployer Apache en mode Prefork, affublé de sa bosse mod_php, malgré tout sereins car en tout état de cause, l’appel à un shared object déjà chargé dans la mémoire virtuelle de votre UNIX favori sera toujours plus rapide qu’une ouverture de socket. Ainsi soit-il.

Emile Heitor
Emile Heitor
Après avoir été CTO de NBS System, Émile conseille désormais nos clients sur leurs projets les plus complexes, notamment sur le Cloud public AWS. Expert reconnu dans le milieu informatique, toujours à la pointe des nouvelles technologies, il sait comprendre et faire comprendre les enjeux et les évolutions du marché IT.