I built the fastest PHP webserver in the world(qbixserver.com) |
I built the fastest PHP webserver in the world(qbixserver.com) |
Nice! I remember 2010 when a single-core pentium 4 was happily doing 18k RPS with Glassfish. Ten more years of progress and you can match that!
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):
EDIT: After reading through the fairly long README, this is mentioned. So you either use the provided server API to make it fast, or use the CGI mode - even for WP, Laravel or Symfony ("legacy", really?)). It'd be better advertised as a framework, using which is the only way to actually achieve the promised results.
I'm also a bit confused by the webserver code itself; it's PHP 5 code (with all the @class and @private annotations, even) that targets 8.1 (EOL) and yields deprecation notices on PHP 8.2.
The taken approach is interesting, but I'd not put this in front of anything that matters.
If you're this uncomfortable with having to run a webserver, but comfortable with a vibecoded webserver, consider switching to Go, .NET or any other stack where you don't have to fight the PHP's inherent shared-nothing model.
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.
It’s a lot of fun working on such things, but the reality is, for most apps, almost any stack is more than fine.
"no Docker" - so what? Docker is a tool. Running containers on Linux has extremely low overhead. No idea what this is about.
You didn't spend the effort to decorate the slop with your rationale for these choices, so I see no evidence that you built any of this.
Now everyone can understand the math.
I wonder if the misconception is from relying on managed database services. Maybe instead of installing their own database, they order one from a service provider like AWS or GCP. That would explain how they'd think that a database like Postgres would have to live on a different machine.
What is the setup/benchmark that caused you to see this?
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.
This framing is confusing because OPcache has for the past 15 years taken care of exactly this bootstrapping you're worried about. In a competing share-nothing setup you merely come in at a tie for performance (barring first run of `require`). I do not see 10-50ms latencies in any of my deploys which is why I'm skeptical.
That said, the big sell of your project for me might be memory management - less memory means more workers which is always a good thing if it comes at no cost to latency.
The general idea makes sense. PHP, particularly modern Java-style PHP, is notorious for loading sometimes thousands of files for every single request. I think there's opcache enabled by default, so the load on the filesystem is reduced by quite a bit, but even opcache still needs to do some sort of parsing for each request that comes in.
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).
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!
I've implemented some of the feedbacks on this thread, including making the README shorter and having it link out to other .md files. The webserver now creates standalone executables that are editable by normies like a redbean server.
On a positive note: the performance is genuinely impressive.. what does it take to unlock this performance if I'm NOT running one of the big "usual" frameworks? The devil is always in the detail, best get some practical advice up on exactly what needs to happen with a medium piece of custom code to get it to said max performance.
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)
As per one of the few, actually non-dangerous to children, children shows produced by the BBC in the 70s
I find this argument kind of unconvincing. At scale you want your components to be rock solid. This project is an interesting experiment, but i would never use it at scale until it matures a lot more.
Heres the template:
"I" <--- prompted some LLM
"built" <--- to generate code for a
"fastest" <-- insert specious claim here
"PHP server" <-- thing
"And I prompted the LLM to build a website" <---- link
Im sorry folks but this just doesnt cut it anymore. I dont think it ever did.
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.
In turn it makes me wonder how do humans do those things? Perhaps it is our human job to apply discretion going forward.
I understand why… people are inundated with more content than ever. Even if it is a huge breakthrough, most won’t care and will just keep posting in a TL;DR way.
I hoped that many on HN would actually take this for a spin. It’s free and MIT-licensed. And if you serve any websites in PHP (as 70% of all websites are), you owe it to yourself to save money and serve more users on one machine. I mean, seriously, this lets you build a PHP app that serves 40,000 users on a $5/month machine. You’d raise your Series A before you need another machine LOL
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.
It's used because it combines the entire environment so I know the app runs the same locally as it does when deployed, without needing to install or configure anything on the server.
You just start the image and it runs.
That's like 1/9th Moby Dick, to put into perspective.
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
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
Look, you are allowed to feel excited about using coding agents but understand we don’t have to lower the bar with the purpose of entertaining your LLM induced delusions of grandeur.
It has some interesting ideas and architecture.
As far as the landing page — there are truly many features that this webserver enables. That’s why the website lists 9 categories and links to other pages. It also has expandable sections like “how can it be this fast?”
I do use LLMs in my toolchain, to generate text and code, and compilers to generate code, but I also cover it heavily with automated tests and also battle-test it in my own environments on actual workloads. I mean sheesh, I am literally sharing it so that you can download and run it yourself, and if you run into something obscure on your environment, report any issues and it’ll be fixed.
The problem is having to wade through it all. I have finite time.
Furthermore, it's not just me associating LLMs with compilers. Linus Torvalds said this 2 months ago. I'm sure you'll find him to be tiresome too... you're much more knowledgeable than all of us: https://www.reddit.com/r/theprimeagen/comments/1ucitd0/linus...
Sorry no offense, but you're not very convincing, when you didn't even bother to look at the software or read the actual package documentation to any extent. You're pattern-matching in this case more than a low-weight LLM here.
I'm Ops person who has supported larger PHP applications. I've had several outages because PHP developer dropped some Apache config to "fix" something that caused HAProxy to disconnect. I've almost never had this with Uvicorn or Net/HTTP.
# Send an extra 0x20 space character after this header's value, because
# otherwise Chrome on Android 15 shifts into compatibility mode and
# it takes 37x longer to render the page, which everyone will blame on
# "the slow webserver". The spec doesn't say we *can't* add this, and
# tells clients to ignore trailing space, and we've tested this with 483
# other clients to demonstrate that it doesn't cause problems. ¯\_(ツ)_/¯ .
BTW, in your showdead (for wholly unclear reasons) comment about it using copy-on-write RAM semantics, that's just the Unix process model. The OS does all that courtesy of fork() and the server gets it for free.
The README is no longer than nginx documentation, though, or many manfiles of programs. The README explains all the features in one file, with results of actual benchmarks. I asked it to put emojis in there as well.
I use LLMs in my toolchain, same as I also use compilers. In fact, I use the LLMs to generate end-to-end test suites, and the test running is automated as well.
> I use LLMs in my toolchain, same as I also use compilers. In fact, I use the LLMs to generate end-to-end test suites, and the test running is automated as well.
Yeah, I could see that.
What do you think?
Your README makes it harder to understand why your project is unique, why the things it says are good are actually good. It's inscrutable LLM marketing-speak that suggests you had very little involvement in the content.
Do you understand why that matters to someone deciding whether to run something you vibe coded?
I was hoping you might address the criticism rather than get defensive. It seems more likely that you are unwilling to defend the content you published.
Amongst other tells, “it’s free and MIT” stated as a noteworthy feature gives strong “how do you do, fellow kids” vibes.
You’ve mentioned the mass of sloppy content you know we’re drowning in. Throwing more slop our way isn’t likely to help things.
Take the ideas from your generated work so far and put your own intellect to work on it. Find someone to bounce ideas off. You might find it fun, and it might provide some human interest worthy of a new HN post in future.
So I now suspect your entire LLM-dar lol