A different take on "worker mode": the Qbix webserver

[gggeek]

Today I read about Qbix, (yet another) "app server for php".

It is a pure-php application, which claims to be able to achieve both excellent speed, low memory usage and great stability by (afaict):

1. loading php classes and doing app. state set-up in the "main process"
2. for each incoming request, forking the "main process" into a new "worker process" which will handle it

The stability part is guaranteed by having 1 worker process per request - no memory leaks out of the box.
The speedup and reduced memory consumption comes from having the worker processes being forked after having the php classes already in memory (and possibly the connections to external services such as DBs open).

While I have not even tried to run it even once, it seems that this might be a good execution model, if not in general, at least for a specific set of php applications, eg. those that take care of routing on their own and are distributed as containers, where there is no need to reload state in case of live changes to the php code.

Can anyone comment on the pros/cons of this vs. the FrankenPHP worker mode?

[AlliBalliBaba]

Sounds interesting, I imagine though that there are lots of subtleties that would need to consider when forking the process.

The pros are obviously that you do not need to tear down the application as you can just the destroy the process at the end of the request.
The cons are that you kind of loose a lot of control over the statefullness. Not sure if it is even possible to keep connections persistent. Wouldn't the child process close connections on teardown? And isn't there a lot of overhead to creating and tearing down a process for each request? (even FPM re-uses processes across requests)

Haven't looked into it though, so maybe they do have solutions to these problems.

[gggeek]

I have not looked into any of those issues in great detail tbh.

Regarding file descriptors (incl. open sockets), they are "kinda-shared"*, so as long as the spawned-off child does not terminate a persistent connection**, things should just work afaik.

But yeah, it seems that this execution model is different enough on the corners that it might not be suited for "just any php application" - one would be trading off the 'do not care about memleaks and shared state' advantage with 'you have to be more careful with persistent connections, pre-opened pipes and sockets and the php engine playing shutdown-tricks behind your back'.

As for the overhead involved with one-process-per-request: I have no idea how big that is compared to the time spent by php to 'init' the engine then load and parse the php files.
Surely for a "hello wold" page it would be a suicidal choice, but it might actually be competitive or even faster for apps which use a lot of code...

I am thinking about building a WAF atm, which is pretty much stateless by design, so it might be a good fit... Of course I might be missing some obvious roadblock, hence my asking

* = a gruelling enough description of how that works can be found f.e. at https://chessman7.substack.com/p/fork-and-file-descriptors-the-unix

** = not sure it is possible to prevent that tbh, unless one can prevent execution of specific php functions. That, and the php engine's "shutdown" routine for the forked processes is not something under control of the php script. Also, calling pConnect after the fork has happened will also have different behaviour, being forced to create a non-persistent connection...