Thread

I built the fastest PHP webserver in the world

44 points · 77 comments · EGreg

Loading the complete thread in the background. This saved snapshot is available now. Refresh

mpalmer · 1789832841 · focus · HN ↗
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.
1. tobz1000 · 1789833252 · focus · HN ↗
  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 functions 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.
  1. ramon156 · 1789833526 · focus · HN ↗
    [delayed]
    iinnPP · 1789834069 · focus · HN ↗
    In the specific context though, it is relevant. So your aside is more closely related to the behavior you're outlining.
    LoganDark · 1789836138 · focus · HN ↗
    Really wish I could use Gemini without linking it to my personal Google account.
  2. DenisM · 1789838520 · focus · HN ↗
    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.
  3. EGreg · 1789865091 · focus · HN ↗
    I honestly consider it lazy pattern-matching commenting slop if people don’t look at the actual software being described, don’t run it, don’t even open the sections of the webpage that describe how it works.
    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
    mpalmer · 1789866763 · focus · HN ↗
    I admit I did not expect an accusation of laziness.
    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.
    EGreg · 1789867101 · focus · HN ↗
    If I was unwilling to defend it, why did I sit for 30 mins on an iPhone and personally type all the substantive replies to toplevel comments in this thread?
    bbg2401 · 1789875644 · focus · HN ↗
    Your replies are directly from an LLM too.
    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.
    EGreg · 1789878215 · focus · HN ↗
    I literally wrote them on an iPhone myself.
    So I now suspect your entire LLM-dar lol
2. bel8 · 1789833458 · focus · HN ↗
  In the context of PHP it is notable to be able to run production grade without nginx in front of it.
  PHP doesn't have a production grade built-in server like .NET's Kestrel.
3. vachina · 1789834004 · focus · HN ↗
  PHP is stable enough to not need Docker.
  As in there’s very little ways to fuck up a PHP setup.
  1. tcfhgj · 1789835186 · focus · HN ↗
    then find out you need to install and configure a series of php extensions
    confusedbucket · 1789840902 · focus · HN ↗
    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.
  2. nilamo · 1789838920 · focus · HN ↗
    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.
4. EGreg · 1789864926 · focus · HN ↗
  Most PHP requires additional webservers, such as nginx, and process managers like php-fpm, to even serve websites.
  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!
LoganDark · 1789833402 · focus · HN ↗
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.
1. iinnPP · 1789833731 · focus · HN ↗
  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.
  1. LoganDark · 1789835910 · focus · HN ↗
    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.
2. conductr · 1789837379 · focus · HN ↗
  Why do you need a dedicated server at all? A $7 droplet/vps would handle the full stack
  1. LoganDark · 1789841189 · focus · HN ↗
    I meant a server dedicated to the database, but yes, I agree. Never said the web server had to be bare metal.
3. EGreg · 1789864068 · focus · HN ↗
  The goal is to optimize everything other than the database. The vast majority of PHP apps are I/O bound and this webserver lets you handle 100x as many users as php-fpm. That’s the point. Your code can remain the same and keep using whatever database.
BatchJob · 1789834253 · focus · HN ↗
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.
1. ceejayoz · 1789834497 · focus · HN ↗
  I saw someone promote their new simple framework today. It was all TODOs.
  1. EGreg · 1789864550 · focus · HN ↗
    And this one has a working webserver you can run in one command, a graphical user interface and real-time dashboard, tests to prove the claims, and example apps to make it easy to start. Not to mention that you can run your existing PHP apps unmodified with it just like you can with php-fpm.
    ceejayoz · 1789864785 · focus · HN ↗
    All that may be true! Some of these projects are genuinely awesome.
    The problem is having to wade through it all. I have finite time.
2. bliteben · 1789834522 · focus · HN ↗
  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.
3. croisillon · 1789835094 · focus · HN ↗
  Just because LLMs can write copy for webpages doesn't mean they should. A landing page should not warrant a tl;dr.
  <a href="https://news.ycombinator.com/item?id=49665895">https://news.ycombinator.com/item?id=49665895
  1. EGreg · 1789864817 · focus · HN ↗
    The grandfather comment is pants-on-fire wrong. “No need to click” while they opine on something you’ve never seen.
    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.
4. okeuro49 · 1789836736 · focus · HN ↗
  I think that is far to harsh actually.
  It has some interesting ideas and architecture.
5. EGreg · 1789864393 · focus · HN ↗
  I think what’s happening is: I spend months iterating and building software, that makes some major breakthroughs over existing software. I am able to do this by using LLMs in my toolchain, as well as automated testing suites, and compilers. I don’t write assembly language by hand.
  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.
  1. bbg2401 · 1789874916 · focus · HN ↗
    There are no breakthroughs. And your attempts to closely associate LLM’s with compilers is tiresome.
    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.
    EGreg · 1789882149 · focus · HN ↗
    Wrong on both points. Yes, there are clearly breakthroughs since it can handle 100x more users at the same time than PHP-FPM, also it handles everything else including websockets, etc.
    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: <a href="https://www.reddit.com/r/theprimeagen/comments/1ucitd0/linus_torvalds_took_the_stage_at_open_source/" rel="nofollow">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.
etchalon · 1789834488 · focus · HN ↗
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.
1. carlosjobim · 1789835399 · focus · HN ↗
  You're confusing HN with your email inbox again. The link wasn't sent to you specifically.
  1. Capricorn2481 · 1789836563 · focus · HN ↗
    What a tedious reply. They're asking what the technical reasons for wanting that would be. You're reading it in the silliest way possible.
    carlosjobim · 1789836940 · focus · HN ↗
    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.
    nashashmi · 1789840213 · focus · HN ↗
    [delayed]
    Capricorn2481 · 1789856823 · focus · HN ↗
    If you read the comment for more than half a second you'd see they're not questioning why someone would use PHP.
    Signed, a PHP developer.
2. stackskipton · 1789835853 · focus · HN ↗
  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.
  1. bawolff · 1789836418 · focus · HN ↗
    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.
    kstrauser · 1789837156 · focus · HN ↗
    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.
    stackskipton · 1789844315 · focus · HN ↗
    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.
    bawolff · 1789856189 · focus · HN ↗
    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.
dingdingdang · 1789835327 · focus · HN ↗
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.
1. bawolff · 1789836200 · focus · HN ↗
  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.
2. sourthyme · 1789837416 · focus · HN ↗
  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.
3. 0gs · 1789838774 · focus · HN ↗
  whoa.
  is clanger:clanker::darn:damn? a softer touch. i like it
  ok ok, or "dang"
  (or did i mandela myself)
  1. 0gs · 1789838808 · focus · HN ↗
    def tripped over those asterisks
  2. dingdingdang · 1789979130 · focus · HN ↗
    Yeah, gotta say clangers are softer* than clankers clearly. It was a slip but might adopt due to the plush connotations.
    As per one of the few, actually non-dangerous to children, children shows produced by the BBC in the 70s
bawolff · 1789835333 · focus · HN ↗
for reference this is the interesting bit:
> run many workers. The server loads your entire framework into a parent process, then calls pcntl_fork() to create workers. The kernel marks the parent’s pages copy-on-write. Workers share every loaded class — they only pay for pages they actually write to during the request.
So its essentially preloading the memory layout. Cool idea.
tommica · 1789835884 · focus · HN ↗
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!
1. EGreg · 1789863944 · focus · HN ↗
  Indeed. And funny enough, by writing it in PHP, I was able to make it spawn 100x as many workers on the same machine, and thus serve more users. Try it
dmitrijbelikov · 1789835984 · focus · HN ↗
You should look at Workerman
1. progx · 1789837504 · focus · HN ↗
  Workerman does something else.
dreadnip · 1789836811 · focus · HN ↗
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.
1. brandon272 · 1789837815 · focus · HN ↗
  What do you mean LLM slop? OP says they built it themselves.
  1. thrance · 1789837968 · focus · HN ↗
    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.
    EGreg · 1789863770 · focus · HN ↗
    Yes, I actually iterated a lot on that README and personally directed the LLM to produce every section in there, as an artifact. Normally it would produce a much shorter README, and I should probably have split it up. That is exactly what I did on the actual website.
    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.
    thrance · 1789903814 · focus · HN ↗
    I don't care how much you were or were not involved with the README, no one is reading through all that. If you can't be arsed to, at the very least, write the prose around your project, why should we devote any time engaging with it?
    > 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.
    EGreg · 1789935573 · focus · HN ↗
    Alright, so version 1.3 has a much shorter README: <a href="https://github.com/Qbix/webserver" rel="nofollow">https://github.com/Qbix/webserver
    What do you think?
  2. thomasmg · 1789838612 · focus · HN ↗
    There are very clear signs this was mostly built by an LLM. Just an example: <a href="https://github.com/Qbix/webserver#%EF%B8%8F-architecture" rel="nofollow">https://github.com/Qbix/webserver#%EF%B8%8F-architecture misaligned lines, the commit history, etc.
    EGreg · 1789863623 · focus · HN ↗
    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.
  3. wavemode · 1789839447 · focus · HN ↗
    [delayed]
2. EGreg · 1789863527 · focus · HN ↗
  Oh, it is far more useful than some “psychosis”, this is real, and battle-tested. Have you tried to download and run it yourself? It comes with its own tests and even several example apps out of the box.
  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:
  <a href="https://github.com/Qbix/webserver" rel="nofollow">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
mschuster91 · 1789836839 · focus · HN ↗
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.
1. noir_lord · 1789837498 · focus · HN ↗
  > 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].
  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.
  There is also FrankenPHP which negates 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).
  The build and throw away the world solution does mitigate/obviate some issues but has it's own issues (memory leaks and the like become more of an issue in long lived worker processes), as always the final answer is "it depends".
  [1] <a href="https://wiki.php.net/rfc/make_opcache_required" rel="nofollow">https://wiki.php.net/rfc/make_opcache_required
  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).
2. EGreg · 1789865278 · focus · HN ↗
  Whether the opcache is enabled or not, the vast majority of production PHP code is I/O bound - workers wait for the network or filesystem or database.
  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!
nzeid · 1789838275 · focus · HN ↗
> php-fpm re-bootstraps the framework on every request (10–50ms)
What is the setup/benchmark that caused you to see this?
1. EGreg · 1789863226 · focus · HN ↗
  It’s not about a benchmark. PHP-FPM executes your .php file from the beginning every time, so it does require(…) all the classes etc. and then proceeds to load the configuration from files etc.
  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.
  1. nzeid · 1789924866 · focus · HN ↗
    > A good framework can maybe cache some of this with the opcode cache, and apcu. Saving some milliseconds.
    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.
    EGreg · 1789935546 · focus · HN ↗
    Yep, you got it. The big difference is the memory savings, not as much the saving milliseconds per request, although that might be useful too if it takes 40-50ms to bootstrap and load configs every time.
pshirshov · 1789838289 · focus · HN ↗
> 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!
1. EGreg · 1789862474 · focus · HN ↗
  Glassfush was Java not PHP, and it was also using AOT (ahead-of-time) loading of bytecode, similar to what this does for PHP classes.
christophilus · 1789838681 · focus · HN ↗
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.
confusedbucket · 1789838843 · focus · HN ↗
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 wont.
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, maybe switching to something like Go or .NET is the right choice.
1. EGreg · 1789862209 · focus · HN ↗
  Actually, there is a “fork” mode that outperforms php-fpm by about 100x. That is, it allows the webserver to spawn 100x more processes on the same machine (tested) on Linux and Mac. The trick is that the pcntl_fork() is done after loading the classes, so because the OS does copy-on-write of memory pages, each child process takes up maybe 4-200KB. One 4GB machine can handle 40,000 simultaneous users.
  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.
garbageinout · 1789840402 · focus · HN ↗
[dead]
EGreg · 1790054250 · focus · HN ↗
It's funny, after it got 1 point, this got re-posted by the hosts on HN for a second change, got 44 points, and subsequently flagged for some reason.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.