3 ms·

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 happ

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?

Fizzadar 14y ago
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.
seabee 14y ago
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)
mnutt 14y ago
He doesn't post much about his setup to know for sure, but it's possible that he was running out of ephemeral ports.
lazyjones 14y ago
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).
- rartichoke 14y ago
  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.
- magnetikonline 14y ago
  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 http://blog.engineyard.com/2012/linux-scalability

Fizzadar 14y ago

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.

seabee 14y ago

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)

mnutt 14y ago

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

lazyjones 14y ago

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

rartichoke 14y ago
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.
magnetikonline 14y ago
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 http://blog.engineyard.com/2012/linux-scalability