PHP 5x plus rapide que NestJS ? Swoole et les coroutines C réinventent le high-load

Depuis des années, le consensus dans l'industrie semblait gravé dans le marbre : pour du haut débit, de la concurrence massive et des microservices, on choisit Node.js (NestJS) ou Go. PHP, lui, traînait la réputation d'un langage « old-school », plombé par son cycle request-response et le coût de démarrage du framework à chaque requête.

Un benchmark publié récemment sur DEV Community par Roman Shneer vient bousculer ce postulat. En construisant un processeur d'événements haute fréquence capable d'encaisser 10 000+ requêtes par seconde avec PHP 8.4 + Swoole, il obtient des résultats qui surpassent NestJS d'un facteur 5 en débit, avec une latence plancher nettement inférieure. Décryptage.

Le problème du PHP traditionnel (et pourquoi Node.js avait l'air de gagner)

Avec PHP-FPM, chaque requête déclenche le démarrage complet du processus : chargement de l'autoloader Composer, boot du kernel Symfony ou Laravel, initialisation des services… C'est fiable, c'est prévisible, mais c'est coûteux à très haute fréquence. L'analogie du restaurant qui embauche et licencie tout son personnel à chaque client est cruelle, mais juste.

Node.js a résolu ce problème avec sa boucle d'événements persistante. Une seule instance reste en mémoire et traite les requêtes de façon asynchrone via l'event loop. Pour de nombreux cas d'usage I/O-bound, c'est une nette amélioration.

Mais l'event loop V8 atteint ses limites quand le nombre de Promises concurrentes explose. La gestion des microtâches, le passage de contexte JavaScript et le coût de async/await s'accumulent sous une charge de dizaines de milliers de connexions simultanées.

Swoole : un moteur de coroutines natif C dans votre PHP

Swoole n'est pas une simple bibliothèque asynchrone. C'est une extension PHP écrite en C qui transforme en profondeur le modèle d'exécution :

1. Coroutines C vs Event Loop JavaScript

Là où NestJS s'appuie sur l'event loop et l'overhead de async/await, Swoole introduit des coroutines en espace utilisateur gérées au niveau C. Le changement de contexte n'intervient que lors des opérations I/O, sans passer par le scheduler du système d'exploitation. Le résultat : un overhead de commutation quasi nul et une capacité à gérer des milliers de coroutines concurrentes avec une empreinte mémoire très faible.

2. Mémoire persistante entre les requêtes

Avec Swoole, le serveur démarre une seule fois. Le kernel Symfony, les connexions base de données, les clients HTTP, les pools Redis — tout reste en mémoire entre les requêtes. On élimine complètement le coût de bootstrap qui pénalise PHP-FPM. C'est l'équivalent d'un serveur Node.js qui garde son état, mais avec la rigueur typée de PHP 8.4.

3. Pools de connexions natifs

Swoole intègre nativement la gestion de connection pools pour MySQL, PostgreSQL, Redis, etc. Chaque coroutine emprunte une connexion au pool, exécute son I/O, puis la restitue — sans bloquer les autres. NestJS peut y parvenir via des bibliothèques tierces, mais avec une couche d'abstraction supplémentaire et un coût en allocation mémoire plus élevé.

Ce que les benchmarks révèlent concrètement

Dans les tests de charge réalisés par Roman Shneer sur un processeur d'événements haute fréquence :

• Débit : l'architecture PHP 8.4 + Swoole atteint ~5x le throughput de l'équivalent NestJS sur un scénario 10k+ RPS
• Latence : le plancher de latence (percentile 50) est significativement plus bas côté Swoole
• Stabilité : la dégradation sous charge reste plus linéaire qu'avec Node.js, qui peut souffrir de pics de garbage collection V8

Ces résultats s'expliquent par la combinaison des trois facteurs décrits ci-dessus : coroutines C, mémoire persistante et pools de connexions natifs.

⚠️ Nuance importante : tout benchmark est contextuel. Ces chiffres correspondent à un workload I/O-bound spécifique (ingestion d'événements). Sur des charges CPU-intensives ou des architectures très différentes, les résultats varieraient. L'intérêt ici est de démontrer que PHP n'est pas structurellement limité pour le high-load.

Ce que ça change pour un projet Symfony

Pour une équipe qui travaille déjà en PHP/Symfony, l'adoption de Swoole ouvre des perspectives concrètes :

• FrankenPHP (basé sur un serveur Go + PHP intégré) ou RoadRunner (serveur d'application Go) permettent d'obtenir des bénéfices similaires à Swoole avec une intégration Symfony plus simple
• Le composant Symfony Runtime supporte RoadRunner nativement, ce qui réduit la friction à l'adoption
• Les Symfony Messenger workers bénéficient directement d'une architecture persistante : plus de cold start à chaque message consommé
• Il faut toutefois être vigilant sur la gestion de l'état : dans un serveur persistant, les fuites mémoire et les variables statiques mal gérées peuvent devenir problématiques entre les requêtes

L'article source est à retrouver sur DEV Community — PHP is 5x Faster Than NestJS? Rethinking High-Load with Swoole.

Conclusion

Le mythe du PHP lent sur les charges élevées repose sur une réalité aujourd'hui dépassée : celle de PHP-FPM et de son modèle de processus éphémères. Avec Swoole — ou des alternatives comme RoadRunner et FrankenPHP — PHP rejoint le cercle des runtimes capables de tenir des charges de production sérieuses, en tirant parti d'un modèle de coroutines plus efficace que l'event loop JavaScript pour les scénarios I/O-bound.

Cela ne signifie pas qu'il faut réécrire tous ses services NestJS en PHP. Cela signifie que si votre équipe maîtrise PHP et Symfony, vous n'avez pas à changer de stack pour adresser des exigences de performance élevées. Le bon outil dépend du contexte — et PHP 8.4 est un outil bien plus affûté qu'on ne le croit souvent.