Concurrence

Dix mille connexions qui dorment, cent appels sortants à lancer d’un coup, un calcul qui devrait occuper tous les cœurs : un jour ou l’autre, vos requêtes cessent d’être indépendantes les unes des autres, et c’est là que commence votre troisième question. PHP n’a ni threads dans sa version standard, ni boucle d’événements intégrée. La concurrence lui vient des processus, de bibliothèques bâties sur les coroutines que le langage a ajoutées en 8.1, et de runtimes qui apportent leur propre boucle d’événements. Chacune de ces trois réponses convient à certaines charges et échoue sur d’autres, et c’est cette différence qu’il faut connaître avant de lui confier un service.

Beaucoup de requêtes

Un worker qui attend 40 millisecondes une réponse de la base occupe un processus pendant 40 millisecondes, et aucune autre requête ne s’en aperçoit. Tout le modèle tient là, pour le cas ordinaire des requêtes HTTP indépendantes : le pool de processus du chapitre Le runtime, où chaque worker bloque sur sa requête SQL, sa lecture de cache ou son appel HTTP sortant pendant que le système d’exploitation fait tourner les autres. Un runtime à boucle d’événements comme Node.js a besoin de code asynchrone pour qu’un appel lent ne gèle pas toutes les connexions. PHP a préféré donner un processus à chaque connexion, et le code reste synchrone.

Cette simplicité se paie en mémoire, connexion par connexion. Un worker qui garde un WebSocket ouvert, qui attend la fin d’un long poll ou qui diffuse une réponse pendant une minute immobilise un processus entier tout ce temps, et un pool de quelques centaines de processus ne tiendra jamais dix mille connexions inactives. Pour cette charge-là, le modèle par défaut de PHP est le mauvais.

Beaucoup de connexions

Pour les charges qui exigent de nombreuses connexions simultanées dans un seul processus, PHP dispose de runtimes asynchrones, et ce sont des bibliothèques ou des extensions, pas des fonctionnalités du langage. Par ordre alphabétique : AMPHP, un ensemble de bibliothèques non bloquantes construites sur une boucle d’événements et sur les fibers du langage ; ReactPHP, un ensemble de bibliothèques bas niveau pilotées par les événements, avec sa propre boucle, son serveur HTTP et ses composants de flux ; Swoole enfin, ou son fork OpenSwoole, une extension en C qui donne à PHP une boucle d’événements, des coroutines et un serveur HTTP et WebSocket intégré, avec des appels d’entrées-sorties qui rendent la main au lieu de bloquer. FrankenPHP et RoadRunner, les runtimes worker du chapitre Le runtime, ne figurent pas dans cette liste parce qu’ils répondent à un autre besoin : ils gardent l’application chargée entre deux requêtes, toujours une requête à la fois par worker, et ne rendent pas le code concurrent.

Sous les deux premiers se trouve la Fiber, arrivée en PHP 8.1 : une fonction capable de se suspendre elle-même, et que celui qui la tient peut reprendre plus tard. La RFC qui l’a introduite dit très précisément ce qu’elle n’est pas : « toutes les fibers vivent dans un seul thread, une seule fiber s’exécute à la fois », et « le code bloquant, comme file_get_contents(), continuera de bloquer le processus entier, même si d’autres fibers existent ». Le langage ne fournit aucun ordonnanceur. C’est une bibliothèque qui l’apporte, et chaque appel d’entrée-sortie du programme doit passer par elle pour rendre la main. Une application PHP asynchrone s’écrit donc contre le client HTTP, le client de base de données et les fonctions de fichiers d’AMPHP ou de ReactPHP, et non contre les fonctions standard. Une seule bibliothèque synchrone glissée par mégarde dans les dépendances bloque toute la boucle.

Jusqu’où une boucle d’événements porte PHP, le test plaintext du benchmark multi-langages le montre : il ne fait aucun travail applicatif et mesure seulement combien de connexions en pipeline une couche HTTP sait servir.

L’entrée Swoole sert 3,5 millions de requêtes par seconde, devant Micronaut, Gin, Node.js et Spring, quand PHP nu sous PHP-FPM en sert 450 000 et Laravel sous PHP-FPM 27 000. Le plafond est ailleurs : ASP.NET Core à 11,5 millions, et tout en haut un serveur Python adossé à du C et un serveur Rust, autour de 28 millions. Avec une boucle d’événements, PHP joue dans le deuxième groupe, pas dans le premier. Sans, il joue dans le quatrième.

Beaucoup de cœurs

Le programme spectral-norm le plus rapide en PHP dans le Benchmarks Game termine en 18 secondes de temps réel pour 72 secondes de CPU réparties sur plusieurs cœurs, contre 90 secondes pour le meilleur programme Python et 1,6 seconde pour Node.js. Cet écart entre temps CPU et temps réel, c’est à cela que ressemble le calcul parallèle en PHP, et une fois de plus il vient des processus. L’interpréteur en ligne de commande forke avec pcntl_fork(), lance des sous-processus avec proc_open() ou fait tourner plusieurs scripts sous un superviseur, et les résultats reviennent par des tubes, des fichiers, une base ou une file d’attente. L’extension parallel propose bien des threads, mais sur la version thread-safe de l’interpréteur, que peu de distributions livrent. Le parallélisme par fork fonctionne, et il fonctionne dans la classe de vitesse de l’interpréteur décrite dans Débit et latence.

L’ordonnanceur entrera-t-il un jour dans le moteur ? La question est ouverte sur la liste internals. Une RFC intitulée « Concurrency Support in the PHP Engine », qui ajouterait un ordonnanceur et de la concurrence structurée au langage lui-même, y était en discussion au moment où j’écris, sans vote, après qu’une première proposition sur le même sujet a été abandonnée en juillet 2026. En septembre 2026, le langage a des fibers, et l’ordonnanceur est une bibliothèque.

Ce qui ne doit pas faire attendre l’utilisateur

La concurrence dont vous aurez besoin le plus souvent n’a rien de spectaculaire : c’est le travail que l’utilisateur ne devrait pas avoir à attendre. Une requête a une durée limite et une réponse à rendre, donc tout ce qui prend plus de temps doit en sortir. L’idiome, c’est une file d’attente et un processus worker. La requête dépose un travail dans une table ou un courtier de messages, puis répond. De son côté, un script PHP en ligne de commande, maintenu en vie par un superviseur, dépile la file et exécute les travaux un par un. Ce script n’a ni limite de temps ni limite de mémoire tant que vous ne lui en donnez pas, alors un worker de production fixe les deux et s’arrête proprement après quelques milliers de travaux, pour que le superviseur relance un processus neuf. La plupart des frameworks full-stack livrent ce schéma avec un pilote pour les courtiers habituels, et cron couvre les tâches planifiées.

La limite : la concurrence de PHP est à gros grain. Des processus pour les requêtes, des processus pour les cœurs, une file d’attente pour le travail en arrière-plan, et un runtime à part, avec ses propres bibliothèques d’entrées-sorties, pour le cas des connexions nombreuses. Si votre produit est un service temps réel avec des dizaines de milliers de connexions ouvertes, vous passerez votre premier mois à choisir puis à apprendre l’un des runtimes asynchrones, et vous découvrirez que la plupart des bibliothèques de l’écosystème n’ont pas été écrites pour lui. Si votre produit est fait de requêtes et de réponses, vous ne rencontrerez jamais la question.

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

Prenez le scénario à connexions nombreuses que vous avez vraiment, si vous en avez un, et écrivez-le deux fois dans l’après-midi : une fois avec AMPHP ou ReactPHP, une fois avec Swoole ou OpenSwoole. Comptez ensuite combien des bibliothèques dont vous dépendriez offrent un client non bloquant. Si c’est la plupart, la voie asynchrone vous est ouverte. Si elles sont rares, la conclusion honnête est que PHP est le mauvais outil pour ce service-là, et le reste de votre système est une décision à part.

Reste à savoir si le langage lui-même est de ceux que vous auriez envie d’écrire, et cette question-là, vous y répondez en le lisant.