> Its asynchronous, non-blocking architecture means it’s incredibly fast.
Those characteristics mean it can handle more simultaneous connections, but don't directly lead to more speed. I feel that is worth nitpicking about. Nodejs is pretty fast, but I think that has more to do with V8, libev, libio, and Ryan's http parser being really fast.
I've actually found evented servers to be slower than threaded servers in microbenchmarks. This is because evented servers have their own share of overhead:
- an I/O multiplexor syscall must be called from time to time. Select/poll/kqueue/etc. These extra syscalls introduce overhead on top of the already required read/write calls.
- the event loop has some overhead too.
- the fact that read never blocks means that the kernel can't apply certain optimizations such as having the peer directly write to the receiver's read buffer instead of copying things though multiple buffers.
That said, I think microbenchmarks like this are bullshit. The overhead is so small that you never notice a difference in production. The benefits of evented architectures are clear: you can handle a much larger concurrency level and you use less memory thanks to not having to reserve so many threading resources.
However too many people seem to be ignorant about this and think microbenchmakrs mean something. All they care about is that 10000 req/sec > 8000 req/sec.
I am actually looking into switching Phusion Passenger to an evented architecture, but I'm a little reluctant to do so because I fear people would microbenchmark it, see that it's slower and conclude that Passenger X sucks and is slower than Passenger X-1 or $COMPETITOR.
Those characteristics mean it can handle more simultaneous connections, but don't directly lead to more speed. I feel that is worth nitpicking about. Nodejs is pretty fast, but I think that has more to do with V8, libev, libio, and Ryan's http parser being really fast.