Out of all runtimes powering web servers today, I like PHP the most for its shared-nothing architecture, preventing a whole lot of security bugs by default. I think making it evented for HTTP is clutching defeat from the jaws of victory. You win very little, because most web servers code is I/O bound.

With 8GB RAM and no virtual memory swapfile, Qbix Server allows you to handle, say, 1600 concurrent HTTP requests and 40,000 websocket connections simultaneously, so having an HTTP handler PHP process exit and be respawned via fork is cheap (0.5ms to reset it to a state with all the bootstrap already done). Processes simply yield when doing I/O and you let the OS handle the I/O waiting instead of green threads in an event loop. It’s almost as fast, and frankly, dynamic PHP can be 2% or less of all your requests, when you start aggressively sending Cache-Control headers causing this Qbix webserver to cache your PHP results, as well as nginx/varnish and CDNs upstream too.

I have no particular interest in using this piece of software, but I would still celebrate and defend the notion that people can have little ideas like this, get something working and then share it with others to move forward with.

1. To share an innovation we developed for ourselves, that can help the wider PHP community (after all, 80% of the Web still runs on PHP!)

2. To pioneer a new approach that can help a bunch of people, like Caddy or FrankenPHP had once pioneered its own approaches

3. To show that PHP by itself can be enough to not only build a decent web server, but actually surpass NGINX together with PHP-FPM both in memory and speed, which surprised us. The memory particularly turns out to be the bottleneck and Qbix Server finally helps solve the 10K issue for PHP!

4. To make a new and very simple way to cleanly build websites and APIs that leverage both HTTP Requests and WebSockets: simply drop appropriately named files in the right places! It is optionally opinionated so the shapes of new codebases using the server, instead of all being ad-hoc, can be standardized along the same lines our own are.

5. To get feedback from the HN community. Speaking of that:

Could you please list the reasonably obvious security issues, so they can be fixed?