Outside of the prefork mode (which cannot compete even with just FPM/Apache mod), this has a bunch of isolation issues that I don't see mentioned anywhere; namely statics in functions (often seen as a request-lifetime cache in PHP), typed statics without defaults, define(), $_ENV, setlocale(), ignore_user_abort() or mb_internal_encoding() just to name a few. It also assumes all function/class declarations are guarded, so this isn't a drop-in replacement for a webserver that "just works"; for most code, it probably doesn't, so the "unmodified PHP" claim seems like a stretch.
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.
Sort of unrelated, but I recently built an http server in Odin to learn the language. It’s a pleasant language, and very low memory usage, if managed well. Around 50k requests per second on my old laptop. The surprising thing was that Bun matched it (albeit at 50MB RAM usage vs 3MB for Odin).
It’s a lot of fun working on such things, but the reality is, for most apps, almost any stack is more than fine.
People have been using pcntl_fork to speed up PHP code since the 90s. It seems good on paper, can produce an "impressive" demo and falls apart quickly on real world projects and use cases. This is nothing more than LLM slop/psychosis.
You don't need your database on a dedicated server. Not sure why the comparison table claims "$30 + DB server" when your web server is a perfectly good server already.
Presumably to remove it from the need to calculate. Everyone is using a different approach and one DB may require a lot more than the 30$ server can provide.
The claim is presumably that a web server running SQLite is that much better than a web server running Postgres or Redis. So they end up including it in the calculation anyway but only on one side... so it's just simply not even apples to apples.
I meant a server dedicated to the database, but yes, I agree. Never said the web server had to be bare metal.
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.
You can see the slop through the headline. No need to click. Posts like this are turning the internet into a trash pile. Nobody needs this slop, abandonware.
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.
I for one do not get the hate, nobody needs to use/or-waste-time-commenting on this project if they have no need/want. However, I do agree that it needs some more contributors on-board alongside with a couple months more support and bug squashing. And yes: better rewrite that website without the clanger involved in the wording! ;)
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.
I was kind of wondering too. I assume this only works if you load a lot of classes before touching request specific variables. That might work for big framework, but you probably have to rewrite a lot if not using one.
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.
I think we are all afraid that an LLM could generate a ridiculously fast webserver and be production viable. But I'm still glad we are taking this through the ringer.
I'm confused why the copy you generated repeatedly boasts "no nginx, no Redis" as if those things don't exist independently of application servers for a reason, and as if building something that doesn't need these things (when deployed as a single instance) is particularly notable.
"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.
One of the biggest shortcomings I often see with LLM-produced content, following a planning conversation, is that they misunderstand the breadth of the domain for which a detail is relevant or interesting.
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.
The only LLM that does this wel (in my opinion) is gemini. if i ask claude to fix comments, it very clearly fails in doing so. Gemini actually seems to understand the scope of a task
Docker isn't used because it helps run unstable programs.
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.
And get rid of all the hardcoded paths, domains, things that only make it work on the specific OS the previous person was using even though there's nothing in the app that would justify it. And then one day, someone introduces Docker, that will make it work everywhere, only now you have to start the containers in some specific order and comprehend some complicated volume setup and it runs 10x slower.
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).
It's generally easier to have language self-host itself because at scale, you will be running multiple instances of the application so instead of Ingress Controller -> Go self-hosted/Python Uvicorn, it becomes Ingress COntroller -> Apache -> PHP and if developer modifies the Apache in ways you are not expecting, stuff can break.
I mean at scale you probably have TLS termination -> caching layer -> webserver -> fpm -> php. All probably written in different languages.
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.
First off, alot of companies don't have caching layer. It's not different languages, it's the fact that you have really capable webserver underneath. It's HAProxy -> Apache -> PHP vs HAProxy -> Golang (Net/HTTP) or HAProxy -> Python (Uvicorn) with a lot less knobs to manipulate.
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.
Of course it depends on what type of application you are running whether a caching layer like varnish makes sense. I'm not saying its universal just really common if you are operating at scale.
I agree. Nginx, Caddy, Apache, etc have found and fixed a million edge cases you'd never think of just from reading and implementing the spec. I guarantee there's code in each of these along the lines of:
# 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. ¯\_(ツ)_/¯ .
Now, as a very cool hack, or for easier local development with one less dependency, or just to scratch a personal itch and see if it can even be done, right on! That's clever and I'm glad they did it!
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.
PHP is stil the backbone of the internet and a great tool. I don't think that anybody has to explain why people would want to use it.
If somebody doesn't want anything to do with PHP that's their decision, but why clog up the threads? And every HN post has a similar dismissive comment. Why?
If you read the comment for more than half a second you'd see they're not questioning why someone would use PHP. They're asking why you would use this particular server over nginx/apache, given how robust their support is.
They are asking about why would you need an alternate system? What is the technical reason behind it? What’s the disadvantage in the current system? All while acknowledging that they used to work in PHP and haven’t recently so they understand a lot less.
Outside of the prefork mode (which cannot compete even with just FPM/Apache mod), this has a bunch of isolation issues that I don't see mentioned anywhere; namely statics in functions (often seen as a request-lifetime cache in PHP), typed statics without defaults, define(), $_ENV, setlocale(), ignore_user_abort() or mb_internal_encoding() just to name a few. It also assumes all function/class declarations are guarded, so this isn't a drop-in replacement for a webserver that "just works"; for most code, it probably doesn't, so the "unmodified PHP" claim seems like a stretch.
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.
> 1060 req/s
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!
Sort of unrelated, but I recently built an http server in Odin to learn the language. It’s a pleasant language, and very low memory usage, if managed well. Around 50k requests per second on my old laptop. The surprising thing was that Bun matched it (albeit at 50MB RAM usage vs 3MB for Odin).
It’s a lot of fun working on such things, but the reality is, for most apps, almost any stack is more than fine.
> php-fpm re-bootstraps the framework on every request (10–50ms)
What is the setup/benchmark that caused you to see this?
People have been using pcntl_fork to speed up PHP code since the 90s. It seems good on paper, can produce an "impressive" demo and falls apart quickly on real world projects and use cases. This is nothing more than LLM slop/psychosis.
What do you mean LLM slop? OP says they built it themselves.
There are very clear signs this was mostly built by an LLM. Just an example: https://github.com/Qbix/webserver#%EF%B8%8F-architecture misaligned lines, the commit history, etc.
over 100K lines of code materialized over the course of 3 weeks and is full of em dashes. I think we can reasonably assume here...
Yeah, and surely they also wrote the 131KB unreadable-wall-of-text README themselves.
That's like 1/9th Moby Dick, to put into perspective.
You should look at Workerman
Workerman does something else.
I love the idea of being able to remove the webserver from my stack, and be able to give that job to php too. Less deps!
You don't need your database on a dedicated server. Not sure why the comparison table claims "$30 + DB server" when your web server is a perfectly good server already.
Presumably to remove it from the need to calculate. Everyone is using a different approach and one DB may require a lot more than the 30$ server can provide.
Now everyone can understand the math.
The claim is presumably that a web server running SQLite is that much better than a web server running Postgres or Redis. So they end up including it in the calculation anyway but only on one side... so it's just simply not even apples to apples.
Why do you need a dedicated server at all? A $7 droplet/vps would handle the full stack
I meant a server dedicated to the database, but yes, I agree. Never said the web server had to be bare metal.
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.
You can see the slop through the headline. No need to click. Posts like this are turning the internet into a trash pile. Nobody needs this slop, abandonware.
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.
I feel like HN has had posts like this for 15 years. This one is just an opportunity to discuss where php falls with llms in the mix.
I think that is far to harsh actually.
It has some interesting ideas and architecture.
I saw someone promote their new simple framework today. It was all TODOs.
Just because LLMs can write copy for webpages doesn't mean they should. A landing page should not warrant a tl;dr.
https://news.ycombinator.com/item?id=49665895
I for one do not get the hate, nobody needs to use/or-waste-time-commenting on this project if they have no need/want. However, I do agree that it needs some more contributors on-board alongside with a couple months more support and bug squashing. And yes: better rewrite that website without the clanger involved in the wording! ;)
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.
I was kind of wondering too. I assume this only works if you load a lot of classes before touching request specific variables. That might work for big framework, but you probably have to rewrite a lot if not using one.
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.
I think we are all afraid that an LLM could generate a ridiculously fast webserver and be production viable. But I'm still glad we are taking this through the ringer.
whoa.
is clanger:clanker::darn:damn? a softer touch. i like it
ok ok, or "dang"
(or did i mandela myself)
def tripped over those asterisks
I'm confused why the copy you generated repeatedly boasts "no nginx, no Redis" as if those things don't exist independently of application servers for a reason, and as if building something that doesn't need these things (when deployed as a single instance) is particularly notable.
"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.
One of the biggest shortcomings I often see with LLM-produced content, following a planning conversation, is that they misunderstand the breadth of the domain for which a detail is relevant or interesting.
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.
The only LLM that does this wel (in my opinion) is gemini. if i ask claude to fix comments, it very clearly fails in doing so. Gemini actually seems to understand the scope of a task
In the specific context though, it is relevant. So the aside is more closely related to the behavior being outlined.
Really wish I could use Gemini without linking it to my personal Google account.
I observed the same, and generalized it as inability to recognize salience and more broadly apply discretion.
In turn it makes me wonder how do humans do those things? Perhaps it is our human job to apply discretion going forward.
In the context of PHP it is notable to be able to run a production grade web server without nginx/apache/docker in front of it.
PHP doesn't have a production grade built-in server like .NET's Kestrel.
PHP is stable enough to not need Docker.
As in there’s very little ways to fuck up a PHP setup.
You just turn it on and it runs.
Docker isn't used because it helps run unstable programs.
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.
then find out you need to install and configure a series of php extensions
And get rid of all the hardcoded paths, domains, things that only make it work on the specific OS the previous person was using even though there's nothing in the app that would justify it. And then one day, someone introduces Docker, that will make it work everywhere, only now you have to start the containers in some specific order and comprehend some complicated volume setup and it runs 10x slower.
s/you built/you spent LLM tokens to build/g
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.
> I think there's opcache enabled by default.
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
I haven't used PHP as a daily workhorse in a decade, so I guess I don't understand why I would want a web server in pure PHP? Nginx exists.
It's generally easier to have language self-host itself because at scale, you will be running multiple instances of the application so instead of Ingress Controller -> Go self-hosted/Python Uvicorn, it becomes Ingress COntroller -> Apache -> PHP and if developer modifies the Apache in ways you are not expecting, stuff can break.
I mean at scale you probably have TLS termination -> caching layer -> webserver -> fpm -> php. All probably written in different languages.
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.
First off, alot of companies don't have caching layer. It's not different languages, it's the fact that you have really capable webserver underneath. It's HAProxy -> Apache -> PHP vs HAProxy -> Golang (Net/HTTP) or HAProxy -> Python (Uvicorn) with a lot less knobs to manipulate.
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.
Of course it depends on what type of application you are running whether a caching layer like varnish makes sense. I'm not saying its universal just really common if you are operating at scale.
I agree. Nginx, Caddy, Apache, etc have found and fixed a million edge cases you'd never think of just from reading and implementing the spec. I guarantee there's code in each of these along the lines of:
Now, as a very cool hack, or for easier local development with one less dependency, or just to scratch a personal itch and see if it can even be done, right on! That's clever and I'm glad they did it!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.
[flagged]
What a tedious reply. They're genuinely asking what the technical reasons for wanting that would be. You're reading it in the silliest way possible.
PHP is stil the backbone of the internet and a great tool. I don't think that anybody has to explain why people would want to use it.
If somebody doesn't want anything to do with PHP that's their decision, but why clog up the threads? And every HN post has a similar dismissive comment. Why?
Unless you think HN is a personal inbox...
If you read the comment for more than half a second you'd see they're not questioning why someone would use PHP. They're asking why you would use this particular server over nginx/apache, given how robust their support is.
Signed, a PHP developer.
They are asking about why would you need an alternate system? What is the technical reason behind it? What’s the disadvantage in the current system? All while acknowledging that they used to work in PHP and haven’t recently so they understand a lot less.
[dead]
[dead]