FrankenPHP : un serveur d’applications PHP moderne

 (frankenphp.dev)
4 points par GN⁺ 2024-05-31 | 1 commentaires | Partager sur WhatsApp
  • Dans les flux de déploiement visant à lancer des apps PHP sans PHP-FPM séparé, FrankenPHP est un serveur d’applications basé sur Go qui intègre l’exécuteur PHP officiel à Caddy, afin d’exécuter des apps web PHP et des scripts CLI avec une seule commande
  • HTTP/1.1, HTTP/2, HTTP/3, certificats HTTPS automatiques, compression Brotli/Zstandard/Gzip, journalisation structurée et métriques Prometheus sont regroupés parmi les fonctionnalités de base, ce qui réduit la configuration serveur
  • Le Worker mode démarre l’application une fois et la conserve en mémoire ; selon ses propres benchmarks sur une app API Platform, il serait 3,5 fois plus rapide que FPM
  • Compatible avec PHP 8.2+, la plupart des extensions PHP et les modules Caddy, il prend aussi en charge nativement des extensions populaires comme OPcache et XDebug
  • La prise en charge des images Docker, de Kubernetes, des plateformes cloud et du déploiement sous forme de binaire statique autonome peut simplifier l’unité de déploiement des apps PHP

Mode d’exécution et flux d’utilisation de base

  • FrankenPHP se présente comme un serveur d’applications PHP moderne écrit en Go, avec une installation et une exécution d’apps PHP centrées sur une seule commande
  • Les exemples d’installation sont répartis par système d’exploitation
  • L’exécution locale couvre à la fois le serveur web et la CLI
    • frankenphp php-server -r public/ : servir le répertoire public/
    • frankenphp php-cli script.php : exécuter un script PHP en ligne de commande
  • L’exécution avec Docker utilise aussi la même image
    • Servir le répertoire public/ avec l’image dunglas/frankenphp
    • Possibilité d’exécuter des scripts CLI comme php script.php depuis la même image
  • La configuration est basée sur Caddy ; l’exemple de configuration active la compression dans un bloc localhost et traite les fichiers PHP et les assets statiques du répertoire courant avec php_server

Fonctionnalités serveur et compatibilité PHP

  • Fonctionnalités de serveur web

    • Intègre l’exécuteur PHP officiel à Caddy
    • Prise en charge native de HTTP/1.1, HTTP/2 et HTTP/3
    • Automatise la création, le renouvellement et la révocation des certificats HTTPS via Let’s Encrypt ou ZeroSSL
    • Prise en charge intégrée de la compression Brotli, Zstandard et Gzip
    • Inclut la journalisation structurée et la prise en charge de Prometheus

  • Environnement d’exécution PHP

    • Compatible avec PHP 8.2+, la plupart des extensions PHP et tous les modules Caddy
    • Prend en charge nativement les extensions PHP populaires, dont OPcache et XDebug
    • Ne nécessite pas PHP-FPM et utilise sa propre SAPI conçue pour le serveur web Go

Worker mode et fonctionnalités orientées performance

  • Le Worker mode démarre l’application une fois puis la conserve en mémoire, afin qu’elle soit prête à traiter les requêtes en quelques millisecondes
  • Pris en charge nativement par Symfony, API Platform et Laravel
  • Utilise les superglobales PHP existantes, sans PSR-7
  • Même si l’application n’est pas compatible avec le Worker mode, elle peut être servie telle quelle
  • Fournit un watcher qui redémarre automatiquement les workers lors des changements de code
  • Présenté comme 3,5 fois plus rapide que FPM dans ses propres benchmarks sur une app API Platform

Déploiement et packaging

  • Possibilité de déployer des apps cloud native avec des images Docker
  • Compatible avec Kubernetes et les plateformes cloud modernes
  • Possibilité de packager des applications web PHP et des outils en ligne de commande sous forme de binaire statique autonome
  • Décrit comme fonctionnant avec un seul service et un seul binaire, sans service externe nécessaire

Fonctionnalités web supplémentaires

  • Prend en charge les 103 Early Hints, présentés sur la base d’un article de Cloudflare comme une fonctionnalité pouvant améliorer le temps de chargement des sites web de 30 %
  • Grâce au hub Mercure intégré, les apps PHP peuvent envoyer des événements aux navigateurs connectés, qui reçoivent immédiatement la charge utile sous forme d’événements JavaScript
  • Prend en charge les déploiements sans interruption avec le graceful reload

À lire aussi

1 commentaires

 
GN⁺ 2024-05-31
Avis sur Hacker News
  • Je n’ai quasiment pas fait de développement PHP depuis près de 10 ans, mais cette landing page m’a presque donné envie de lancer ne serait-ce qu’un hello world
    Le personnage d’éléphant façon Frankenstein est bizarre, moche et mignon à la fois. Le design, les couleurs, les textes et les animations sont aussi soignés. Pour quelqu’un qui s’est éloigné du développement PHP depuis un moment, la proposition de valeur ressort bien, et ça semble adapté pour démarrer rapidement quelque chose de petit
    • Je suis passé de PHP à Golang il y a un peu plus de 10 ans, parce que la distribution sous forme de binaire était vraiment appréciable
      Je n’ai pas envie de lancer 8 conteneurs pour isoler des logiciels médiocres ou des dépendances emberlificotées. Je n’aime pas l’idée d’emballer un « ça marche sur ma machine » et de le balancer au monde au lieu de fournir un logiciel installable. Par nostalgie, je pourrais y jeter un œil, mais je ne suis pas sûr d’avoir encore envie de mettre ce genre de chose en production
    • C’est l’une des meilleures landing pages que j’aie vues. C’est amusant et immédiatement compréhensible
  • J’ai longtemps fait du C# et je code maintenant surtout en PHP 8 ; c’est un excellent langage pour construire rapidement quelque chose
    Le langage devrait aller dans cette direction, plutôt que vers l’approche à l’ancienne de LAMP, avec une configuration Apache un peu complexe
    • Je fais du PHP depuis 18 ans, et avec nginx + php-fpm, 5 minutes suffisent pour la configuration
      Je compte aussi essayer celui-ci, mais je n’ai jamais rencontré de goulot d’étranglement avec nginx ou Apache. Dans les deux cas, on les lance en quelques minutes tout au plus
    • Il existe aussi une autre option, Nginx Unit : https://unit.nginx.org/
      Il s’exécute comme un service unique, à la manière d’Apache + mod_php, gère le multiprocessing pour PHP et d’autres langages, les fichiers statiques et le reverse proxy, et permet de piloter à la fois lui-même et PHP dans une seule configuration, à l’exécution, via un fichier ou un socket : https://unit.nginx.org/configuration/#php
      Un exemple de configuration réelle se trouve ici : https://github.com/PrivateBin/docker-unit-alpine/blob/master..., et l’image de conteneur obtenue peut aussi rester assez petite : https://hub.docker.com/r/privatebin/unit-alpine
    • Je configure rarement PHP, mais d’après ce dont je me souviens l’avoir fait à chaque réinstallation de mon poste, avec apt-get c’était très rapide et fluide
      À part redémarrer Apache, je ne me souviens pas avoir eu grand-chose d’autre à faire
    • Je me demande si la configuration d’Apache est vraiment si mauvaise. Avec quelque chose comme PHP-FPM, ça semble plutôt correct : https://news.ycombinator.com/item?id=40256843
      C’est à peu près LoadModule proxy_fcgi_module "/usr/lib/apache2/modules/mod_proxy_fcgi.so" et SetHandler "proxy:fcgi://127.0.0.1:9000". Il y a aussi un exemple Nginx conceptuellement similaire à la façon de configurer Apache, avec même l’installation des paquets nécessaires : https://news.ycombinator.com/item?id=37443911
      Il existe aussi des images de conteneur préconstruites qui donnent un résultat similaire, mais si l’on veut voir comment ça fonctionne en interne, on peut le faire soi-même. C’est clairement plus simple que de configurer manuellement Tomcat ou GlassFish sur les anciens serveurs d’applications Java, et même si une commande d’exécution unique est préférable dans n’importe quel environnement, LAMP n’est pas si mauvais par rapport à d’autres stacks
    • D’accord. Si une culture s’installe autour de SQLite au lieu de PostgreSQL/MySQL, toute l’application côté serveur pourrait devenir un simple binaire autonome
      Avec un binaire, il devient aussi plus facile de l’intégrer dans une app Electron
  • En développement, j’utilise souvent le serveur web intégré de PHP : php -S 0.0.0.0:8000 public/index.php
    Mais il est monothread et lent, donc pas fait pour la production. FrankenPHP semble prometteur, mais le problème de limite de cœurs/threads[2] pourrait aussi poser souci en production. Cela dit, je pourrais l’essayer sur le projet pure-todo[1] pour voir s’il y a le même problème. L’image Docker par défaut a l’air assez bonne
    1 : https://github.com/sandreas/pure-todo
    2 : https://github.com/dunglas/frankenphp/discussions/294
    • La documentation indique explicitement que le serveur intégré de PHP n’est pas destiné à la production, mais uniquement au développement
      Voir l’avertissement en haut de page : https://www.php.net/manual/en/features.commandline.webserver...
      Je ne suis pas sûr que ce soit vraiment une comparaison équitable dans ce contexte
    • En définissant PHP_CLI_SERVER_WORKERS, on peut l’exécuter avec plusieurs threads
    • Je me demande si le fait qu’il ne soit pas utilisable en production tient uniquement aux performances
      Pour un petit site avec peu d’utilisateurs, j’aimerais savoir ce qu’on perd par rapport à d’autres environnements « prêts pour la production »
    • Les problèmes précis qui le rendent impropre à la production, à savoir le fait qu’il soit monothread et lent, sont justement ceux que ceci est censé résoudre, si j’ai bien compris. Il devrait probablement en résoudre d’autres aussi
  • Je l’ai essayé moi-même et c’était vraiment lent ; il ne semblait pas non plus utiliser correctement les cœurs. J’ai passé un long moment sur une documentation insuffisante, sans parvenir à résoudre le problème
    On dit qu’il est prêt pour la production en quelques commandes et 3,5 fois plus rapide que FPM, mais dans mon environnement il tournait à environ 1 % des performances de FPM. J’ai aussi essayé l’exécutable, avec le même problème, et pour un hello world j’aurais attendu au moins 200K rps
    • Je suis le créateur de FrankenPHP. J’aimerais vraiment recevoir un exemple reproductible

Dans la plupart des benchmarks, quand le mode worker est activé, FrankenPHP est généralement bien plus rapide que FPM, environ 3 fois plus. Il existe toutefois quelques exceptions, que nous corrigeons avec les mainteneurs de PHP.

  • Partager votre expérience nous aiderait à résoudre cela : https://github.com/dunglas/frankenphp/discussions/294
    C’est assez étrange, car Caddy lui-même offre de très bonnes performances lorsqu’il est utilisé avec PHP.
  • Je suis curieux de voir ce que ça donnera dans les benchmarks TechEmpower : https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...
    Pour l’instant, il est tout en bas avec la mention did not complete.
  • Article connexe : Show HN: FrankenPHP, un serveur d’applications pour PHP écrit en Go - https://news.ycombinator.com/item?id=33205282 - octobre 2022, 83 commentaires
  • https://github.com/dunglas/frankenphp/discussions/294
    Il y a un problème de performance. En dehors de cela, c’est un projet vraiment prometteur.
    • Si je pouvais le reproduire, je prendrais volontiers 2 semaines de congé de mon entreprise pour le corriger. Personne n’a indiqué comment le reproduire.
  • J’ai benchmarké WordPress avec FrankenPHP et Apache Mod-PHP, et je n’ai pas vu d’éléments montrant que FPHP l’emporte.
    Cela dit, je n’ai pas creusé en profondeur, et les tests ont été faits dans Docker plutôt que dans une configuration classique. WordPress était aussi quasiment en configuration par défaut, sans thème lourd, donc les conditions n’étaient pas réalistes. J’aimerais quand même refaire les tests et mieux comprendre.
    • Contrairement à Laravel et Symfony, WordPress ne prend pas encore en charge le mode worker de FrankenPHP, donc il n’y a pas beaucoup d’avantage côté performances.
      En revanche, 103 Early Hints permet de précharger les assets et de réduire la latence de chargement des pages de 30 %. FrankenPHP facilite aussi l’activation du cache HTTP avec WordPress et simplifie le déploiement. Il existe également un projet dédié à WordPress et FrankenPHP, avec un cache HTTP intégré adapté à WordPress utilisant la bibliothèque Go Souin : https://github.com/StephenMiracle/frankenwp
    • C’est peut-être le nom qu’on utilise par habitude, mais la solution standard avec Apache est d’utiliser proxy_fcgi.
      Cela permet d’économiser un peu de mémoire côté Apache et de laisser plus de marge pour traiter davantage de requêtes PHP.
  • docker run -v $PWD:/app/public -p 443:443 \ dunglas/frankenphp
    Si vous voulez créer vous-même un conteneur Docker pour servir l’application, les commandes suivantes semblent suffisantes pour transformer un Debian fraîchement installé en conteneur nécessaire : apt install -y apache2 libapache2-mod-php et la configuration de /etc/apache2/sites-enabled/000-default.conf.
    Avec des amis, nous maintenons un dépôt qui montre comment passer de zéro à une application web en cours d’exécution avec plusieurs langages et frameworks populaires : https://github.com/no-gravity/web_app_from_scratch
    • J’ai commencé il y a un mois à travailler dans une entreprise qui utilise mod_php, et c’est pénible.
      Chaque fois que j’active xdebug, je dois redémarrer Apache après la session de débogage. Depuis hier, j’ai commencé à configurer apache2 pour utiliser php-fpm, et je me demande si ce FrankenPHP pourrait nous convenir, au moins pour l’environnement de développement. Cela dit, je n’ai pas trouvé dans la documentation comment installer des extensions PHP.
    • Sauf erreur de ma part, je ne pense pas que cela fonctionne. Le virtual host Apache 000-default.conf par défaut redirige-t-il 443 vers 80 ?
  • Ça fait plaisir de voir ça en première page de HN.
    FPM et son architecture sans partage ont été essentiels au succès de PHP il y a longtemps, mais j’ai aussi l’impression qu’ils sont devenus ses chaînes.