[pbowyer]

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

[apocalyptic0n3]

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.

[xorcist]

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.

[kijin]

PHP-FPM has a ton of debugging, logging, and performance-tuning options, but in most popular distros most of them are disabled by default. If you get a Dockerfile from somewhere and just tweak pm.max_children, you're likely to end up with all the helpful stuff commented out.

[xorcist]

Not reading the manual for software your production environment is built on? Surely you are joking.

[noduerme]

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.

[jijji]

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.

[lapser]

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.

[jijji]

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.

[amq]

PHP-FPM has been extremely reliable in my experience.

[whenlambo]

Been using php-fpm with nginx for many-many years (and with caddy since recently) and had zero problems with it.

[habibur]

My experience had been the opposite.

PHP-FPM had been more resilient than the other services I run. Rock solid.