Live data from Hacker News

Lua vs Node vs LuaNginx

pointlessramblings.com

11–15 of 15 posts

Re: Lua vs Node vs LuaNginx

#11
> 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 (?).

Re: Lua vs Node vs LuaNginx

#12

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

Re: Lua vs Node vs LuaNginx

#14
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.

Re: Lua vs Node vs LuaNginx

#15

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?

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

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

Post reply on HN