A PHP server that can handle 10x as many concurrent requests as Nginx+PHP-fpm

A PHP server that can handle 10x as many concurrent requests as Nginx+PHP-fpm(github.com)

25 points by EGreg 10 hours ago | 7 comments

sceptic123 4 hours ago |

I'm curious on the goal of releasing software like this, it's making some crazy claims right out of the gate, but is obviously not production ready or battle hardened. There's some reasonably obvious security issues and not a single test of any kind in the project.

EGreg 1 hour ago | |

The goals are several:

1. To share an innovation we developed for ourselves, that can help the wider PHP community (after all, 80% of the Web still runs on PHP!)

2. To pioneer a new approach that can help a bunch of people, like Caddy or FrankenPHP had once pioneered its own approaches

3. To show that PHP by itself can be enough to not only build a decent web server, but actually surpass NGINX together with PHP-FPM both in memory and speed, which surprised us. The memory particularly turns out to be the bottleneck and Qbix Server finally helps solve the 10K issue for PHP!

4. To make a new and very simple way to cleanly build websites and APIs that leverage both HTTP Requests and WebSockets: simply drop appropriately named files in the right places! It is optionally opinionated so the shapes of new codebases using the server, instead of all being ad-hoc, can be standardized along the same lines our own are.

5. To get feedback from the HN community. Speaking of that:

Could you please list the reasonably obvious security issues, so they can be fixed?

bfoag 4 hours ago | |

I could understand your criticism if this was link to a flashy marketing page or a blatant attempt to sell something - but this is a github repo with an MIT license, what exactly is the problem?

I have no particular interest in using this piece of software, but I would still celebrate and defend the notion that people can have little ideas like this, get something working and then share it with others to move forward with.

sceptic123 3 hours ago | | |

I'm questioning what the purpose is of pushing it at this point in the project lifecycle. It may not have a fancy website but it is making flashy marketing claims in that readme. How about being upfront about the maturity of the project before making the kind of comparisons that it does.

mixdup 1 hour ago | | |

I mean this thing is "Part of the Qbix platform" and there is an offer to sell services related to the "Qbix platform"

blain 6 hours ago |

I wonder if it would be possible to run Wordpress on this. The issue with Workermen or Swoole is that they doesnt provide request data through globals and some headers are absent which Wordpress is a heavy user of.

andai 5 hours ago | |

Several of the WordPress sites I've worked on were CPU bottlenecked, so I'm not sure if this would have helped. (We had one that took 10+ seconds to build the page... I joked that we were running a static site generator on each HTTP request. My joke was not appreciated!)

znpy 4 hours ago | | |

> so I'm not sure if this would have helped.

maybe not on cpu but surely on memory

EGreg 1 hour ago | |

Should absolutely be possible, yes. What headers are usually missing?

edelbitter 5 hours ago |

At the expense of being unreachable if a single client does not play nice?

EGreg 5 hours ago | |

Not at all. You are probably thinking of evented programming that happens in Node, Swoole or FrankenPHP. Qbix server makes sure each PHP process is isolated, so you also don’t leak any memory or secrets across requests.

Out of all runtimes powering web servers today, I like PHP the most for its shared-nothing architecture, preventing a whole lot of security bugs by default. I think making it evented for HTTP is clutching defeat from the jaws of victory. You win very little, because most web servers code is I/O bound.

With 8GB RAM and no virtual memory swapfile, Qbix Server allows you to handle, say, 1600 concurrent HTTP requests and 40,000 websocket connections simultaneously, so having an HTTP handler PHP process exit and be respawned via fork is cheap (0.5ms to reset it to a state with all the bootstrap already done). Processes simply yield when doing I/O and you let the OS handle the I/O waiting instead of green threads in an event loop. It’s almost as fast, and frankly, dynamic PHP can be 2% or less of all your requests, when you start aggressively sending Cache-Control headers causing this Qbix webserver to cache your PHP results, as well as nginx/varnish and CDNs upstream too.

oriettaxx 8 hours ago |

I am very curious about it

it looks great, but too new of course: waiting for others'feeds