Im curious about security features, which are one of the main reasons I have been using Hiawatha.
Nxweb – Fast and Lightweight Web Server
51–60 of 75 posts
Re: Nxweb – Fast and Lightweight Web Server
#52https://github.com/facebook/proxygen
C++, used by Facebook in production.
We have been using it in a high performance RTB application and has performed remarkably well.
Re: Nxweb – Fast and Lightweight Web Server
#53Earlier quoted context omitted.
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.
> 40k/sec http requests (no pipelining) per core is about as fast as it gets unless you move TCP into user space.
I think it can be micro-optimized beyond that. With predictions to avoid unnecessary syscalls, with syscalls grouped together to make cpu more efficient for the rest of the time it spends in event loop, and if it's possible to modify kernel a bit - with batching syscalls together to make them very cheap.
Re: Nxweb – Fast and Lightweight Web Server
#54I am so glad to see nginx is there to give a competition that Nxweb deserves.
Re: Nxweb – Fast and Lightweight Web Server
#55Earlier quoted context omitted.
Many people observe that as miles-per-gallon gets better and better, it begins to become a deceptive measurement in a way, because going from 10 to 20 mpg is a much, much larger change than going from 30 to 40, or even from 80 to 140. It seems people get a better sense of what's going on to measure gallons per mile. When you start doing that it becomes more clear that going from .0001 gallons per mile to .00001 gallo…
Re: gallons of gas. There's the old puzzle: your spouse gets 100MPG in that super-hybrid-mobile. The salesperson wants to upgrade you for $1000 to the super-duper-hybrid-mobile at 200MPG! Double the mileage! You suggest instead that you get the old truck serviced and replace the plugs, distributor and tailpipe. Estimated cost $1000, and should get you from 10MPG to 11MPG. Which is the better deal? Assuming you both d…
Web servers are not like that. Micro-optimizations only work for benchmarks and very specific load patterns that almost no people have.
Re: Nxweb – Fast and Lightweight Web Server
#56Technical prowess is one thing, support is another. There are 20 times as many openresty questions (although still very few) on stackoverflow than nxweb and the few nxweb questions there are from years ago. I am not sure why is this on hacker news frontpage suddenly.
Re: Nxweb – Fast and Lightweight Web Server
#57Earlier quoted context omitted.
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.
> 40k/sec http requests (no pipelining) per core is about as fast as it gets unless you move TCP into user space. I think it can be micro-optimized beyond that. With predictions to avoid unnecessary syscalls, with syscalls grouped together to make cpu more efficient for the rest of the time it spends in event loop, and if it's possible to modify kernel a bit - with batching syscalls together to make them very cheap.
At some point, your complexity gets bigger than simply coding a state machine that operates directly on the network buffers themselves:
That is to say, I suspect that if micro-optimisations can double our performance, they will be more complicated than just writing a customised ring0 that implements HTTP directly inside the network driver.
Here is how I'm looking at it:
• 10Gb/sec network port
• 4k max requests and responses
• == 1.3 million HTTP requests per second.
Now the problem is that main memory is not much faster than our fastest network: About 15Gb/sec, so what we're talking about here is code and state staying entirely in L1, and streaming the network buffers across the CPU, and responding in one pass, to get that 1.3 million optimal performance.
My dash server gets ~135k HTTP requests per second on localhost (I should be able to approach 300k/sec over a network if I ever get around to it). That's 22% of our optimal performance, and a lot better than any other HTTP server I'm aware of.
At this speed, one of those micro-optimisations `writev()` is actually slower than `write()` -- likely because the code path is shorter in the simpler codebase -- but it illustrates my concern nicely: That we are close to that break-even point with the optimisations we can make. If we make our server bigger and more complicated, it might not make our programs any faster.
That suggests to me that the solution is actually fewer, simpler syscalls, not more, bigger ones.
Re: Nxweb – Fast and Lightweight Web Server
#58Earlier 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.
Many people observe that as miles-per-gallon gets better and better, it begins to become a deceptive measurement in a way, because going from 10 to 20 mpg is a much, much larger change than going from 30 to 40, or even from 80 to 140. It seems people get a better sense of what's going on to measure gallons per mile. When you start doing that it becomes more clear that going from .0001 gallons per mile to .00001 gallo…
That is a very good point, but it's not the argument here: I'm responding specifically to the idea that webserver and webserver+fastcgi are "technically" the same speed.
Running two web servers (one speaking HTTP and one speaking FastCGI) is necessarily going to be slower than running one web server.
This should be obvious, although it might be "not significantly slower", which is why I provided some real numbers from my experience to show at which point it becomes slower by an order of magnitude.
You might also find that it's easier to debug one webserver than two.
Re: Nxweb – Fast and Lightweight Web Server
#59Why? 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); mo…
I only spent a minute on the benchmark page, but it says quite clearly the reqs/s are given in the thousands, and explains each test, as well as the conditions.
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.
Re: Nxweb – Fast and Lightweight Web Server
#60Earlier quoted context omitted.
Many people observe that as miles-per-gallon gets better and better, it begins to become a deceptive measurement in a way, because going from 10 to 20 mpg is a much, much larger change than going from 30 to 40, or even from 80 to 140. It seems people get a better sense of what's going on to measure gallons per mile. When you start doing that it becomes more clear that going from .0001 gallons per mile to .00001 gallo…
That is a very good point, but it's not the argument here: I'm responding specifically to the idea that webserver and webserver+fastcgi are "technically" the same speed. Running two web servers (one speaking HTTP and one speaking FastCGI) is necessarily going to be slower than running one web server. This should be obvious, although it might be "not significantly slower", which is why I provided some real numbers fro…
I don't see how it can become an order of magnitude slower even if your app is effectively a no-op.
Two extra fast cgi encodes and decodes sounds like the whole pipeline is just doing 3x the serialization of a non-fast cgi one. Am I missing some context switching overhead you are implying or something?