Le runtime

L’essentiel de ce que PHP fait bien, et l’essentiel de ce qu’il ne sait pas faire, découle de la façon dont il sert une requête. Une requête PHP démarre sans rien, exécute votre code de haut en bas, envoie sa réponse et est jetée ; la concurrence vient d’un pool de processus, chacun traitant une requête à la fois. Rien ne survit d’une requête à la suivante à l’intérieur du processus, et c’est pour cela qu’on appelle ce modèle shared-nothing : aucun objet application ne reste en vie, pas de boucle d’événements, pas de thread.

Une requête, un processus

Le déploiement standard, c’est PHP-FPM, le gestionnaire de processus FastCGI, derrière un serveur web comme nginx, Apache ou Caddy. Le gestionnaire entretient un pool de processus worker, confie chaque requête entrante à un worker libre, et le worker exécute le script, écrit la réponse et revient dans le pool la mémoire vidée. La taille du pool tient en une ligne de configuration. Une machine avec plus de cœurs fait tourner plus de workers, et plus de machines derrière un répartiteur de charge font tourner plus de pools, sans la moindre coordination entre eux.

Une équipe plateforme remarque d’abord le bon côté de ce modèle. Une requête qui plante, qui fuit ou qui dépasse son temps emporte un worker avec elle et rien d’autre ; le gestionnaire remplace le worker et les autres requêtes n’en voient rien. Une fuite mémoire ne peut pas s’accumuler au-delà d’une requête, si bien qu’une application PHP qui tourne longtemps ne se dégrade pas au fil des jours comme peut le faire un processus qui vit longtemps. Déployer, c’est copier des fichiers puis vider un cache, parce qu’il n’y a aucun processus à redémarrer proprement et aucun état en mémoire à drainer.

Le même modèle a ses coûts, et c’est un ingénieur performance qui les voit en premier. Chaque requête paie l’amorçage de l’application : lire la configuration, câbler les dépendances, enregistrer les routes. Il n’y a pas de cache en processus d’une requête à l’autre, si bien qu’une table calculée une fois par processus dans un autre langage l’est ici une fois par requête, à moins de la ranger en mémoire partagée via l’extension APCu ou dans un cache externe. Les connexions à la base de données s’ouvrent et se ferment à chaque requête, sauf à les configurer comme persistantes, si bien qu’un pool de connexions, quand il en faut un, vit hors de PHP. Une charge qui doit garder un état entre les requêtes, un serveur WebSocket ou un salon de jeu, n’entre pas du tout dans ce modèle, et Concurrence explique ce qui y entre à la place.

OPcache, le préchargement et le JIT

L’objection évidente à un amorçage à chaque requête, c’est le coût d’analyser et de compiler le source à chaque fois, et PHP l’a levée en 2013. OPcache garde la forme compilée de chaque fichier en mémoire partagée, si bien qu’un fichier est compilé une fois par déploiement et non une fois par requête. Il fait partie de la distribution standard depuis PHP 5.5 et il est activé dans le modèle php.ini-production livré avec elle ; un benchmark lancé sans lui ne mesure rien de PHP.

Le préchargement, arrivé avec PHP 7.4, va un cran plus loin. Une liste de fichiers est compilée et liée au démarrage du gestionnaire puis gardée en mémoire, si bien que les classes existent avant la première requête et qu’aucun autoloading n’a lieu. La RFC qui l’a introduit a mesuré un gain de 30 % sur la page hello-world d’un framework et de 50 % sur celle d’un autre, et précise dans le même paragraphe que les gains en conditions réelles « seront probablement plus faibles » et dépendent du rapport entre l’amorçage et le travail effectif.

Le compilateur JIT, ajouté dans PHP 8.0 à l’intérieur d’OPcache, compile les chemins de code chauds en code machine, et ses propres notes de version sont plus sobres que les gros titres. php.net indique que le JIT traçant « montre des performances environ 3 fois meilleures sur des benchmarks synthétiques et une amélioration de 1,5 à 2 fois sur certaines applications spécifiques de longue durée », et que « les performances d’une application typique sont au niveau de PHP 7.4 ». La mesure de la RFC elle-même sur WordPress donnait 326 requêtes par seconde avec le JIT contre 315 sans. Le JIT n’a jamais été activé par défaut : avant PHP 8.4, la taille de son tampon était zéro, et depuis 8.4 un tampon de 64 mégaoctets est réservé mais opcache.jit vaut disable, si bien qu’il faut l’activer explicitement. Une application web en tire peu, un script limité par le CPU peut en tirer beaucoup.

Les runtimes worker

Le seul coût qu’OPcache ne supprime pas est l’amorçage de l’application, et une seconde famille de runtimes le supprime en gardant l’application en mémoire. En mode worker, un processus amorce l’application une fois, puis traite les requêtes en boucle, une à la fois, pendant des milliers de requêtes avant d’être recyclé. Par ordre alphabétique : FrankenPHP, un serveur d’application écrit en Go au-dessus du serveur web Caddy, qui propose aussi bien le mode classique d’une requête par processus qu’un mode worker ; RoadRunner, un serveur d’application lui aussi écrit en Go, qui garde en vie un pool de workers PHP et leur transmet les requêtes par un protocole ; et Swoole, ou son fork OpenSwoole, une extension en C qui donne à PHP sa propre boucle d’événements et son propre serveur HTTP. FrankenPHP est hébergé sous l’organisation php sur GitHub depuis le 8 juin 2025, avec une gouvernance inchangée.

Ce que le changement rapporte dépend entièrement du prix de l’amorçage, et la façon honnête de le montrer est de prendre le même code avec le runtime pour seule variable. Sur un script hello-world nu, où il n’y a aucun amorçage à éviter, Tideways, un éditeur de profileur PHP et membre fondateur de la PHP Foundation sans intérêt dans l’un ou l’autre runtime, a trouvé FrankenPHP en mode classique et PHP-FPM à moins d’un demi pour cent l’un de l’autre, autour de 18 400 requêtes par seconde sur une machine virtuelle à huit cœurs. Sur un framework complet, la suite de benchmarks que Débit et latence lit en détail montre l’entrée Symfony passer de 26 000 requêtes par seconde sous PHP-FPM à 74 000 sous FrankenPHP et 111 000 sous Swoole sur son test Fortunes, sans une ligne changée dans le framework. Les éditeurs et les auteurs de frameworks publient des rapports plus élevés sur leurs propres pages. Je m’en tiens à ces deux chiffres parce que vous pouvez reproduire l’un et l’autre à partir de documents publiés.

Le prix, c’est la perte de la garantie shared-nothing. Un worker qui garde l’application amorcée garde aussi tout ce qu’elle a laissé fuir, si bien que propriétés statiques, caches et ressources ouvertes persistent désormais d’une requête à l’autre, et qu’une classe de bugs que PHP-FPM rendait impossible redevient possible. La documentation de FrankenPHP le dit sans détour : PHP « n’a pas été conçu à l’origine pour des processus de longue durée », et le mode worker est livré avec un compteur de requêtes maximum qui recycle les processus par précaution. Une équipe qui choisit le mode worker endosse la discipline que les équipes Node.js ou Java ont déjà.

Ce que coûte un processus

Vous voudrez un point de référence avant d’ajouter le moindre framework. Sur la machine où j’ai écrit ce livre, un processus PHP 8.3 en ligne de commande, sans script, alloue 2 mégaoctets pour son propre tas, atteint 33 mégaoctets de mémoire résidente en comptant l’interpréteur et ses extensions chargées, et démarre puis se termine en 20 millisecondes, mesuré avec memory_get_usage(true) et /usr/bin/time. Reproduisez ces mesures sur votre matériel, et souvenez-vous qu’un worker PHP-FPM partage avec ses frères les pages en lecture seule de l’interpréteur, si bien qu’un worker de plus coûte moins que le chiffre ne le suggère. La configuration de production de Wikimedia, publiée dans son gestionnaire de tâches, fait tourner huit workers PHP-FPM par conteneur MediaWiki, avec un OPcache de 500 mégaoctets et un cache APCu de 768 mégaoctets, dans un à deux gigaoctets de mémoire par conteneur.

La limite : le modèle shared-nothing n’a ni threads, ni état partagé en processus, ni travail en arrière-plan à l’intérieur d’une requête. Tout ce qui doit survivre à une requête, un pool de connexions, un cache chaud, une tâche planifiée, vit dans un autre processus ou un autre système, et l’architecture autour d’une application PHP en porte la marque. C’est une vraie contrainte, et c’est aussi ce qui rend l’exploitation simple.

Ce que vous pouvez vérifier vous-même

Installez PHP-FPM et un serveur web sur une petite machine virtuelle, activez la page de statut de FPM, et regardez le pool sous un générateur de charge comme wrk ou ab : le nombre de processus, la mémoire par worker et le temps de requête sont là, sous vos yeux. Lancez ensuite le même hello-world sous FrankenPHP en mode worker et comparez. Un après-midi de ce régime vous apprend plus sur le runtime que je ne viens de le faire, et les chiffres seront les vôtres.

Un chiffre de débit ne veut dire quelque chose qu’une fois que vous savez lequel de ces runtimes l’a produit.