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 (?).
11–15 of 15 posts
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 (?).
> 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 (?).
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?
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).
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