I built the fastest PHP webserver in the world

This fork mode is exactly for the type of unmofoeid code you’re talking about — which may have some thing not reset between requests. It is still capable of 10-100x more throughout than PHP-FPM, even in its “prefork” mode. This is a “post-fork” if you will.

The code is compatibke with PHP all the way down to 5, so this webserver can be run on any PHP environment from the last 15 years.

The tests here were also done on one core. Although I am skeptical that PHP after so many years, on much faster CPUs, cannot outperform Java from 20 years ago on slower CPUs.

PS: I wrote a language called U that you can transpile PHP into - and it speeds things up by another factor of 10x even over this webserver, because it’s a compiled language and it transpiles pctl_fork() into something that doesn’t require the OS forking processes (so it works even on Windows):

https://ulanguage.org

Now everyone can understand the math.

So if it fixes a bug where function was accidentally deleting a file, it will update the function's documentation with "does not delete any important files", as if that's a key feature and not just one of a million things it should not do.

The same pattern repeats when an LLM is left to generate its own copy after a brainstorming and architecting session. It has no concept of what's important to the end-user.

PHP doesn't have a production grade built-in server like .NET's Kestrel.

This is an all-in one server. It even handles websockets with socket.io 5 compatibility! Yes, without it, people would additionally resort to Node for socket support and maybe Redis for message passing. One of the features is that this server finally handles it all. PHP for everything!

As in there’s very little ways to fuck up a PHP setup.

You just turn it on and it runs.

These examples include support for socket.io and rooms, which I highly doubt existed in the 90s. So the webserver can be used not just to serve HTTP requests to 40,000 simultaneous online users, but also have an entirely in-memory real-time chat server for 40,000 users (or anything more complex).

After over a decade of writing apps in PHP, I always wondered why we needed all that extra tooling around it just to serve websites. I suspected PHP alone could be faster. I didn’t realize how right I was.

This is an entire webserver and socket server written in pure PHP, meaning you can run web applications without nginx for serving files and websites, certbot for certificates, cron for periodic tasks, node for realtime sockets, etc. It comes out of the box with a user friendly dashboard and control panel, too. There are even standalone binaries you can download for Linux and MacOS that can contain your entire web application:

https://github.com/Qbix/webserver

Originally it was much faster than php-fpm, but now it is also faster than even the fastest PHP runtimes. And unlike those runtimes, it is able to run existing PHP apps without modification!

It’s not slop. It has been tested to be faster than every other PHP webserver. Here is HOW it can be this fast:

The vast majority of PHP apps make blocking I/O calls (to the database, files, network calls etc) While that happens, the thread is blocked.

FrankenPHP, Swoole, amphp and others take the “evented” approach which is much faster, but require all I/O calls to be rewritten to use their async libraries. But most existing PHP code would need a lot of work to be ported to async style, and even if it was, sometimes the async libraries don’t handle everything the mainstream ones do.

Qbix Webserver takes a different approach: it spawns hundreds, sometimes thousands of processes on Linux, Mac etc. When a process is blocked waiting on I/O, the rest of the application can handle thousands of concurrent users.

The reason this works is that that Qbix server allows apps to preload files and classes before it forks the worker processes. It can do this while being written in pure PHP.

While php-fpm can prefork workers, this causes each worker to take up a lot of memory, eg 40MB, duplicating all the bytecode from your entire framework and app. By contrast, Qbix Webserver is able to spawn workers that are around 140KB each for a typical Wordpress app. This is because pcntl_fork on Linux and MacOS only copies on write, so 4-16KB memory pages are only copied when you make a change to a variable. If all the variables are on one page (eg in one array) you can even have workers weighing 4-16KB total, allowing you to run TENS OF THOUSANDS of workers on a 4GB machine.

If you use composer install amphp, your code will use epoll instead, causing your app on Qbix Server to be even more efficient.

This is 2026. It would be great if your PHP was able to work with the latest socket.io and handle rooms and socket connections. Imagine a chat server that’s entirely in memory, and also able to handle 40,000 simultaneous users and connections.

Well, now you can. Qbix Webserver handles HTTP Requests, Websockets and rooms, even HTTP Push (for streaming AI tokens etc).

It also can manage your TLS certificates, run cron jobs, and more.

It supports headers like X-Accel-Redirect which lets you serve files with access control done by your app. (Though these aren’t as fast as nginx because PHP lacks support for sendfile, so if you want additional 2x boost in speed for protected static files, you should proxy these headers to NGINX. For public static files, just use a CDN.)

It even supports something new I invented, X-Cache-Tree allowing your code to cache parts of a webpage. Yes, that’s right — you are no longer required to render an entire page again if only a couple parts of it got invalidated. The X-Cache-Invalidate header can intelligently invalidate many pages at the same time!

Instead of hating on it, why not try it?

Visit github and grab the actual server. Launch it with PHP, and use the visual dashboard in your browser to manage your apps. Enjoy! It’s MIT licensed

A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds.

But regardless of all this, each worker process takes up a lot of memory (the entire framework, etc) which is often megabytes. By contrast, the Qbix webserver forks after you have loaded the classes. Being written in PHP actually gives it an advantage — the workers become much smaller and you can run 100x of them.

This accomplishes what no other PHP webserver has managed to do: give you the speed of Swoole / FrankenPHP while at the samw time let you run unmodified PHP scripts in a “shared-nothing” fork environment, maintaining the strict isolation PHP is known for, so there are no memory leaks or data leaks between requests.

Speaking of that, check out the “full-stack microservice” architecture that allows you to isolate your sensitive credentials / config from the main PHP process, preventing a host of attacks.

Indeed, it's on by default in 8.5 and is no longer considered a non-optional extension (it's compiled in) - you can turn it off at runtime but it will be bundled, largely so they could have it on my default[1][2] and it simplifies integration of something that was universally integrated de facto before that.

It was probably due/overdue but I actually like that they are conservative with which extensions become part of the "core" and in reality almost every packaging of PHP has included it back to 5.5 and having worked on large production systems written in PHP I can't think of a single one that didn't use it it in production.

There is also FrankenPHP (and others) which negate much of that overhead (in worker mode).

While introducing other issues you do have to be careful of that would be less of an issue in "classic" mode (literally what FrankenPHP calls it).

There isn't a tonne of good info out of what you gain in the switch from nginx/php-fpm to FrankenPHP though it does seem like you do gain in some ways (but it's very application dependent).

[1] https://wiki.php.net/rfc/make_opcache_required

[2] https://www.php.net/manual/en/opcache.configuration.php

Roadrunner, FrankenPHP and Swoole try to make it evented like Node, but require you to rewrite all your code to use their libraries. For everything from mysql to curl.

This lets you run your PHP unmodified, in 2 different ways:

1) with long persistent workers, clearing all statics and globals between requests

2) if that doesn’t work, eg because your functions have static variables inside etc. then you can use the fork mode, which can still handle 100x as many users as php-fpm due to the amount of RAM each of the workers takes up aa that’s the point!

From a pragmatic perspective, its unclear to me how much this actually speeds things up. I would assume if using php you probably have complex logic and start up time is not dominating the runtime.

is clanger:clanker::darn:damn? a softer touch. i like it

ok ok, or "dang"

(or did i mandela myself)

What happens is that I have the documentation and front facing websites also generated by LLMs. And many people commenting here didn’t even bother to click through and download the actual software or try it. If you did, you would have seen the tests, and example apps. You would have seen the graphicsl UX and dashboard the server itself enables. The fact that no one even mentioned it suggests to me that the people commenting are ones cutting corners. So me using more automation in addition to compiles and test suites isn’t the issue, if you are unwilling so much as to run it before opining publicly about it. Based solely on a README file.

In particular, this server allows people (like the entrepreneurs on HN) to handle 100x as many simultaneous users than current php-fpm, or be as safe as php-fpm while being as fast as Swoole, Roadrunner, FrankenPHP. Try it.

PS: the same thing happened here: https://news.ycombinator.com/item?id=49665345

It has some interesting ideas and architecture.

https://news.ycombinator.com/item?id=49665895