4 ms·
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
by 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 agoIt 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 agoProbably 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