While Nxweb looks very promising, my first question would be 'Why should I use it over eg Nginx?' It would be helpful to have some direct comparison to other servers on the landing page.
EDIT: Ok, there is a link to some odd benchmarks and it includes performance comparisons to Nginx and others which are not understandable (Nginx 141 req/s and Nxweb 200 / 121 req/s while it's not clear when 200 and when 121); moreover they compare it to Mongoose which is an ORM/ODM
However, that doesn't change the why question at all. Except it could be neat to not need the complication of setting up nginx with uwsgi for those who like the built-in Python/WSGI support.
e.g. node.js has no problem getting 20k/sec per core, but a stall at the wrong time kills every pipelined HTTP request that follows (until you tear down the connection and restart it).
All of this is motivation to rewrite everything in C.
I took part in a few projects that replaced high throughput servers handling mobile network traffic from C++ to Java.
I work at two ad-tech related companies, one large one medium, both use Java from the beginning. And I know other company using Python/Golang as well.
Didn't know C(not C++) is particular popular until today. Note that ad company are pretty business focused, add or remove features for big clients are pretty common, so development efficiency matters a lot.
GC pauses are a killer. They can be worked around, but it takes intensive tuning.
The RTB bidder I wrote many moons ago at a startup was fast as hell, but had problems in the 95th percentile of requests meeting the latency targets, due to GC.
The ad servers at the big ad tech heavy weights are in C++.
Technically, there's no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this.
An HTTP server speaking to a FastCGI application will:
• read the HTTP message
• decode HTTP
• encode FastCGI
• write to application
The FastCGI application will then:
• read the FastCGI message
• decode the FastCGI message
• do application stuff
• encode the FastCGI response
• write to the web server
The webserver then resumes:
• reading the FastCGI response
• decoding the FastCGI response
• writing the HTTP response
Meanwhile, an in-process HTTP server (like nxweb) system will simply:
• read the HTTP message
• decode HTTP
• do application stuff
• write the HTTP response
Less code runs faster; it is obvious to me why this is faster.
> Limitations: > - only tested on Linux
Unlikely, and given his attitude I'm not going to waste my time trying nxweb.
Yeah, nope. Check out H2O if you haven't already https://h2o.examp1e.net/.
1) Why you think that java is slower than C++? Server-side JIT compiles much more optimized code as it is really know what and how to optimize.
2) What about security? Almost half of the problems in security in last days came from native code stuff.
While this seems perfectly plausible, would you happen to know some benchmark backing this claim? Thanks.
citation needed
> native code stuff
That is inaccurate. But if you said that it comes from C memory management issues, that sounds more plausible. We could talk about Rust, but I even think that C++ is usually written in a much safer style than C.
[1] https://groups.google.com/d/msg/openresty-en/aoBL22H8fP4/bJ3...
It looks significantly more flexible than anything nginx offers without having to bolt on a server-side language like PHP - unless nginx has something similar in its millions of modules that I'm not aware of.
(I know about and love nginx SSIs, but the templating here looks more flexible than them.)
