Live data from Hacker News

Show HN: FrankenPHP, an app server for PHP written in Go

frankenphp.dev

41–50 of 93 posts

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#45
post #33

Good. PHP-FPM needs a challenger as anyone who has tried to debug it or its pools knows. Or to tune it (so many modes, so many configuration options). Litespeed's PHP LSAPI [1] shows how good performance can be with other setups. It'll be great if FrankenPHP gets to the same state. 1. https://www.litespeedtech.com/open-source/litespeed-sapi/php

PHP-FPM can be so unreliable too. It'll just go down randomly without any warning or logs at all. As you said, it's impossible to debug what happens there and all you can really do is setup monitoring to detect it went down and automatically restart it.

PHP-FPM has been extremely reliable in my experience.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#46
post #33

Good. PHP-FPM needs a challenger as anyone who has tried to debug it or its pools knows. Or to tune it (so many modes, so many configuration options). Litespeed's PHP LSAPI [1] shows how good performance can be with other setups. It'll be great if FrankenPHP gets to the same state. 1. https://www.litespeedtech.com/open-source/litespeed-sapi/php

PHP-FPM can be so unreliable too. It'll just go down randomly without any warning or logs at all. As you said, it's impossible to debug what happens there and all you can really do is setup monitoring to detect it went down and automatically restart it.

PHP-FPM is very easy to debug. It's as simple as setting it up to use a listening socket in www.conf (located in i.e. /etc/php/8.1/fpm/pool.d) and then running a packet sniffer (i.e. ngrep) to listen on that socket, all messages back and forth are visible at that point.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#47
post #36

What is the difference between this and Roadrunner? It seems to do the same stuff. https://github.com/roadrunner-server/roadrunner

The approach isn't the same: Roadrunner executes php-cli and connects it to its web server through GRPC; FrankenPHP uses an ad-hoc SAPI, it is more like Apache's mod_php, the Go code uses the PHP interpreter as a library, it's all in the same process. RoadRunner only has a worker mode, and can only work with compatible apps; FrankenPHP has a "standard" mode compatible with all existing applications, and a worker mode…

Since it's not using PSR-7, does it mean that you could even run WordPress?

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#48

Earlier quoted context omitted.

typically I find CMake would do this, or Make, to verify dependencies. Coupled with a packaging system, like debian gives you, this is all pretty straightforward. I ran into this yesterday, and turns out I don't want to install docker just to build a program...

Right, but there are as many setups as there are potential users, so even if Debian works, that doesn't mean other linux flavours will work as easily, or flavours of BSDs, and then also Macs, and even WSL, or even just plain old Windows. Having an "everyone gets the same thing, so no one wastes time on bootstrapping" solution is a perfect use-case for Docker. And then once the bugs have been found and fixed, and the…

As an aside, may I ask what people's opinion of running docker containers in prod is? The joke "But it works on my local--" "Then ship your local".

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#49
post #33

Good. PHP-FPM needs a challenger as anyone who has tried to debug it or its pools knows. Or to tune it (so many modes, so many configuration options). Litespeed's PHP LSAPI [1] shows how good performance can be with other setups. It'll be great if FrankenPHP gets to the same state. 1. https://www.litespeedtech.com/open-source/litespeed-sapi/php

PHP-FPM can be so unreliable too. It'll just go down randomly without any warning or logs at all. As you said, it's impossible to debug what happens there and all you can really do is setup monitoring to detect it went down and automatically restart it.

That's interesting, in my experience php-fpm has been very dependable even in demanding situations where we migrate over to new backends without missing a request. PHP applications can be a different story, but php-fpm provides enough knobs to restart problematic applications on demand. It's probably that last part of a PHP stack I'd want to replace.

Debugging application servers in production comes with its own set of difficulties, but I don't see how this one is worse than others. If anything, the ability to start new sockets without restarting the process is a plus.

Re: Show HN: FrankenPHP, an app server for PHP written in Go

#50

I might be missing the obvious but why would you add extra complexity to your infrastrucutre setup when PHP can be run natively from within caddy, apache, nginx via fastcgi.

Removing php-fpm + nginx from a container sounds AMAZING to me. If I can just have one thing in a container (plus a code base), that would be a LOT simpler than: nginx, php-fpm, some init system, and the convoluted configuration needed to get logs out via Docker's logging mechanism.

I've recently changed our nginx/php-fpm containers to caddy/php-fpm

Caddy has a supervisor plugin, so can start php-fpm itself and the containers entrypoint can be Caddy, which achieves similar objectives here that Caddy becomes a PHP application server.

Post reply on HN