Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
76% Positive
Analyzed from 1532 words in the discussion.
Trending Topics
#php#server#llm#webserver#more#code#need#built#probably#doesn
Discussion Sentiment
Analyzed from 1532 words in the discussion.
Trending Topics
Discussion (44 Comments)Read Original on HackerNews
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.
It’s a lot of fun working on such things, but the reality is, for most apps, almost any stack is more than fine.
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!
What is the setup/benchmark that caused you to see this?
That's like 1/9th Moby Dick, to put into perspective.
Now everyone can understand the math.
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)
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).
[1] https://wiki.php.net/rfc/make_opcache_required
[2] https://www.php.net/manual/en/opcache.configuration.php
"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.
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.
PHP doesn't have a production grade built-in server like .NET's Kestrel.
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.
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.
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.
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.
It has some interesting ideas and architecture.
https://news.ycombinator.com/item?id=49665895