Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nxweb – Fast and Lightweight Web Server

nxweb.org

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Nxweb – Fast and Lightweight Web Server

#31

Post by iMerNibor »

geocar wrote: post #25
joosters wrote: post #19

They discount using CGI, which is fair enough, but why not use FastCGI? It's a sensible enough protocol, there are libraries for most languages and there's a good chance that your existing web server supports it. Technically, there's no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this.

> 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 • writ…

I'd imagine encoding/decoding will be really insignificant compared to generating the requested page or fetching data from a database in most, if not all, cases

Re: Nxweb – Fast and Lightweight Web Server

#32

Post by geocar »

iMerNibor wrote: post #31
geocar wrote: post #25

Earlier quoted context omitted.

> 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 • writ…

I'd imagine encoding/decoding will be really insignificant compared to generating the requested page or fetching data from a database in most, if not all, cases

Most websites do not see more than 100 requests per second.

In those cases you are correct: parsing and de-parsing is insignificant compared to the amount of energy the computer is using to heat the room.

However in order to do a trillion requests per day you need around 30 machines using a custom web server, or 300 machines using Fastcgi: In this situation the cost is an order of magnitude.

Re: Nxweb – Fast and Lightweight Web Server

#33

Post by lox »

mp3geek wrote: post #26
amelius wrote: post #24

Does it support HTTP 2, or will it in the future?

https://groups.google.com/forum/?hl=en#!topic/nxweb/8NAnQ0Im... Unlikely, and given his attitude I'm not going to waste my time trying nxweb.

> "No plans so far. Why whould you need it?

Yeah, nope. Check out H2O if you haven't already https://h2o.examp1e.net/.

Re: Nxweb – Fast and Lightweight Web Server

#34

Post by thenomad »

The templating engine is an interesting, and slightly curious, addition here.

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.)

Re: Nxweb – Fast and Lightweight Web Server

#35

Post by geocar »

ex3ndr wrote: post #28
geocar wrote: post #16

Earlier quoted context omitted.

Specifically it's garbage collection. 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).

20k/sec is a joke performance. Java/Scala with Akka handles millions of packages per sec and this is performance.

40k/sec http requests (no pipelining) per core is about as fast as it gets unless you move TCP into user space.

Reports of "millions per sec" are usually talking about messages on established channels across all CPUs.

If you're actually aware of a java based web server that can beat even 150k http requests measured by wrk or similar on local host I'd like to see it.

Re: Nxweb – Fast and Lightweight Web Server

#37

Post by Ace17 »

ex3ndr wrote: post #30

Some questions: 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.

"Server-side JIT compiles much more optimized code as it is really know what and how to optimize."

While this seems perfectly plausible, would you happen to know some benchmark backing this claim? Thanks.

Re: Nxweb – Fast and Lightweight Web Server

#38

Post by mhd »

geocar wrote: post #32
iMerNibor wrote: post #31

Earlier quoted context omitted.

I'd imagine encoding/decoding will be really insignificant compared to generating the requested page or fetching data from a database in most, if not all, cases

Most websites do not see more than 100 requests per second. In those cases you are correct: parsing and de-parsing is insignificant compared to the amount of energy the computer is using to heat the room. However in order to do a trillion requests per day you need around 30 machines using a custom web server, or 300 machines using Fastcgi: In this situation the cost is an order of magnitude.

If you managed to get a trillion requests per day with a "hello world" scenario, you're probably also able to get 270 machines for free from your gullible incubator.

Re: Nxweb – Fast and Lightweight Web Server

#40

Post by geocar »

mhd wrote: post #38
geocar wrote: post #32

Earlier quoted context omitted.

Most websites do not see more than 100 requests per second. In those cases you are correct: parsing and de-parsing is insignificant compared to the amount of energy the computer is using to heat the room. However in order to do a trillion requests per day you need around 30 machines using a custom web server, or 300 machines using Fastcgi: In this situation the cost is an order of magnitude.

If you managed to get a trillion requests per day with a "hello world" scenario, you're probably also able to get 270 machines for free from your gullible incubator.

Most ad servers deliver static or hello-world-style content, doing no database lookups, but logging their results.

RTB systems have about 30-100msec for the entire transaction (and that includes network to the user), so you need better control of your latency anyway.

Post reply on HN