Publié initialement sur hafiz.dev
En avril 2026, un benchmark soigneusement contrôlé a soumis les trois serveurs Laravel Octane à une véritable charge de travail Laravel. RoadRunner a plus que doublé le débit de PHP-FPM. Swoole, le serveur réputé depuis dix ans comme le monstre de performances de PHP, a terminé bon dernier. En dessous du FPM simple.
Un mois plus tard, une société d'hébergement qui a migré des dizaines d'applications Laravel vers Octane a publié ses chiffres de production. Leur verdict sur Swoole : c'est leur option la plus rapide pour les charges de travail lourdes en API, et ils la déploient délibérément pour ces clients précis.
Les deux sources sont compétentes. Tous deux ont publié leur méthodologie. Les deux ont raison.
Cette contradiction est la chose la plus utile que vous puissiez apprendre sur le choix d'un serveur Octane, car elle vous pose la question « quel serveur est le plus rapide ? n'a pas de réponse universelle. La question utile est de savoir quel serveur correspond à votre charge de travail, à votre modèle de déploiement et à l'appétit de votre équipe pour la complexité opérationnelle. Cet article explique ce qu'Octane change réellement, comment les trois serveurs diffèrent sur le plan architectural, pourquoi les tests ne sont pas d'accord et un cadre de décision que vous pouvez appliquer à votre propre application. Je vous dirai également quand la réponse honnête est de ne pas utiliser Octane du tout.
Une requête Laravel standard sur PHP-FPM démarre l'ensemble du framework à partir de zéro. Les fournisseurs de services s'inscrivent, la configuration se charge, le conteneur est connecté, puis votre code s'exécute enfin. Pour une application typique dont le démarrage coûte 10 à 30 ms par requête, plus si vous transportez Filament, Nova ou une lourde pile de packages. Ensuite, la demande se termine et tout est jeté.
Octane inverse cela. L'application démarre une fois par travailleur, reste résidente en mémoire et chaque requête entrante réutilise le framework déjà construit. La taxe de démarrage disparaît de chaque requête sauf la première.
C'est tout le truc. Octane ne rend pas vos requêtes de base de données plus rapides, ne met pas en cache vos réponses et ne parallélise pas votre code (à une exception près, en forme de Swoole, à laquelle nous reviendrons). Si votre point de terminaison passe 200 ms dans MySQL, Octane vous évite le démarrage de 20 ms et laisse les 200 ms intacts. C'est pourquoi je dis aux gens de lire leur profileur avant de lire les benchmarks Octane : si le bootstrap du framework ne représente pas une part significative de votre temps de réponse, commencez plutôt par l'optimisation des requêtes. C’est généralement la plus grande victoire et elle ne comporte aucun risque de migration.
L'installation est la mêm...
[Courte citation de 8% de l'article original]