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.
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.
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.
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.
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!)
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.
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.
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.
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.
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.
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!)
> so I'm not sure if this would have helped.
maybe not on cpu but surely on memory
At the expense of being unreachable if a single client does not play nice?
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.
I am very curious about it
it looks great, but too new of course: waiting for others'feeds