[deleted]
Show HN: FrankenPHP, an app server for PHP written in Go
71–80 of 93 posts
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#72Good. 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.
My experience had been the opposite.
PHP-FPM had been more resilient than the other services I run. Rock solid.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#73Good. 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.
Have to chime in with others... FPM has definitely been the most reliable and easily tweakable system I've had in almost 20 years of PHP work, particularly since I run a lot of legacy code off the same server in different versions of PHP.
I feel like problems with monitoring may be down to lack of proper logging or experience. It's not like FPM is going to leak more memory than your code would in other running contexts. It doesn't "go down" since it spawns a new process for every request. My cold read is that there's something wrong with the code you're running, not with FPM.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#74Not really sure what the pros of this is. Simple to deploy in a docker image? Didn't know that was an issue. I guess performance also takes a hit, and that worker mode is a good amount slower than Swoole?
Some benchmarks against mod_php, nginx+php-fpm and swoole would be nice.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#75If I understand it correctly the idea of worker mode is to have a persistent application running where you can have the same objects in memory from one request to another rather than relaunching the app from scratch (requiring files, constructing objects, fetching data from some database) again for each request.
Is that it?
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#76Earlier quoted context omitted.
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".
Been using docker in prod for over 5 years now...
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#77Earlier quoted context omitted.
I haven't tested it yet, but yes it's a stated goal.
Just some experiences I've had putting large PHP frameworks into strange spaces: 1. Most PHP frameworks are designed to have all state destroyed at the end of a request. I was trying to integrate a commercial ecommerce framework with something like Road Runner and another one that I forget the name of. The framework had a DI system which provides each module with its own private instance of all injected instances, so…
Re (1) how feasible would it be to basically teach the PHP VM the equivalent of fork() so you can do all the booting once but still have a fresh copy of the end result on each request?
I mean, it's not going to be as cheap as getting the thing to actually run in a loop, but it might be enough cheaper than the booting process to be worthwhile.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#78Earlier quoted context omitted.
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.
I don't know if I'd call usage of a packet sniffer "easy to debug". Seems like it's reasonable to expect some debug option that is easy to activate in dev environments that will give you the relevant information.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#79I 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.
What about having 1 Dockerfile but run php-fpm in 1 container with nginx in a 2nd container?
This pattern is common for background workers too, such as running gunicorn + celery in separate containers (Python tools) but the same image is used for both. You can change the CMD at runtime by overwriting it (for example the `command` property in Docker Compose and Kubernetes).
This avoids needing to hack around things at the Docker level to install an init system and it gives you a way to split things out at runtime so you individually scale and log them as needed.
It does mean a change in your app would restart nginx since the image would change for both but this isn't that big of a deal. If that was a deal breaker then you could create separate images for each one to still avoid an init system running in your container.
Re: Show HN: FrankenPHP, an app server for PHP written in Go
#80Earlier quoted context omitted.
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.
I don't know if I'd call usage of a packet sniffer "easy to debug". Seems like it's reasonable to expect some debug option that is easy to activate in dev environments that will give you the relevant information.
The back and forth communication is all that you care about with php-fpm, and rarely do you need to actually see it, unless you have php-fpm configured wrong for instance. The majority of debugging a php application means turning on debugging (i.e. ini_set 'display_errors' On and error_reporting('E_ALL')) and tailing a /var/log/nginx log file looking at what happened in your application.