Lua vs Node vs LuaNginx | Hacker News Reader

Lua vs Node vs LuaNginx

pointlessramblings.com

21 pointsFizzadar13 comments

Yet another hello world ab competition with no source code, setup, kernel parameter info or whatsoever

And this:

> My Lua/LuaJIT implementations don't process/read any header fields, nor do they send any back (it's a simple server) I would expect this is the reason Lua/LuaJIT appears to fast. However it does demonstrate that a single process can easily handle 20,000 requests/s …

facepalm

> And Node is perfect because it'll be working with Javascript on the clientside, and not dealing with the http protocol.

I'm confused. What?

On the results, node didn't budge from 30 to 1000 concurrent connections, while the Lua servers just plain crashed, despite being faster at first. Conclusion: Lua is perfect for servers (?).

No http protocol as in it'll just be socket based.

The Lua servers didn't crash; requests via browser worked fine during/after the benchmark. I'm not sure why ab kept hanging.

Go also hangs at the end with a lot of concurrent requests. I think it has something to do with how it time outs http connections.

Maybe the same thing is happening with Lua?

Also what were the specs of the computer you ran your tests on?

He doesn't post much about his setup to know for sure, but it's possible that he was running out of ephemeral ports.

Does this happen with keepalive on (-k option for ab) as well? If not, it might be some network resource starvation issue (connection tracking or TIME_WAIT, try "sysctl -w net.ipv4.tcp_tw_reuse=1" or "sysctl -w net.nf_conntrack_max=655360" perhaps).

It still happens with -k but I haven't tried the other tweaks.

I gave up micro benchmarking because once you factor in sessions and database access then everything goes in the gutter.

I've had a Go server outperform a Node server (same box, same data, same headers) by 5x when returning large amounts of json or returning large strings in general.

As soon as I had that data get returned by a database instead of hard coded strings using both language's best drivers for that database then the reqs/s evened out, in fact Node ended up performing slightly better for both latency and reqs/s.

Probably more related to "real world" runs than benchmarking, but ramping up connection tracking table space is rarely a good idea - unless you turn of stateful iptables rules entirely (which for a benchmark like this should be fine).

The other (possible) option for real world use is to tweak nf_conntrack_tcp_timeout_time_wait and nf_conntrack_tcp_timeout_established to flush done connections from connection tracking quicker.

Have had some good use with this - read more here: http://blog.engineyard.com/2012/linux-scalability

I did something similar two years ago with Lua + sockets, same experience (but I never persisted with it long enough to figure out why, since my project was finished)

Sounds quite likely the same thing is happening to Lua.

The tests were made on a Micro VPS from Afterburst.com (which I own), on an empty/not-yet-deployed node.

I've successfully made one node server handle over 400K concurrent connections on a 24 core (4*6cores) and 32gb ram. Not with standard configs though. And I know there is more room to grow when the reverse-proxy gets out of the way. However this setup easily saturates 1gbs NIC, and never tested with dedicated 10gb uplink. If you are looking for ACID database application stack then you won't get anywhere near raw output anyway. So don't bother choosing any like you did. But If you are in the nosql business then you might get around some 10k iops with the right set of hardware and config tweaks.

You might want to compare node against luvit.io instead of plain lua+luasocket

Reply on news.ycombinator.com