[Aurel300]

That's not inherent to PHP, but rather the ecosystem it's usually used in. The standard "LAMP" stack, for example, has Apache in it for the actual server, talking to PHP using a CGI interface. So if your PHP script crashes or hangs, the server itself is still up, and capable of serving other clients.

If you set up a Node script where e.g. Express talks directly to the clients, then yes, the script crashing or hanging means the server becomes unavailable or unresponsive. However, you can also set up a layer in front of Node. See cgi-node for replicating the CGI workflow you might be used to.

There are some advantages to the standard Node model though: the program can manage its own resources, such as keeping a database connection open; it can run asynchronous maintenance tasks; it can see and report the current server load; it can easily combine HTTP(S) communication and Web socket streams; etc.

[sgdfhijfgsdfgds]

> The standard "LAMP" stack, for example, has Apache in it for the actual server, talking to PHP using a CGI interface. So if your PHP script crashes or hangs, the server itself is still up, and capable of serving other clients.

Not exactly... the standard, typical LAMP stack makes use of mod_php, so the PHP engine is in-process with one of the Apache process.

The fact that Apache has multiprocess/hybrid workers is actually why the server stays up and can serve more requests.

Some contemporary LAMP stacks use FPM, I guess; most of those in shared hosting ISPs for example because of the possibility of running the script as a user process.

[BirAdam]

I would imagine that FPM is more common than people realize because it’s also usually faster, and running scripts as a separate user is more secure. For example, if PHP is a user with read-only access to the document root, it is far more difficult for an attacker to do file injection.