3 ms·
I think he risks dropped connections because the listen queue can overflow. He doesn't mention increasing somaxconn, which means it probably has a default of 1
by gorset 14y ago
I think he risks dropped connections because the listen queue can overflow.
He doesn't mention increasing somaxconn, which means it probably has a default of 128 (I don't think increasing tcp_max_syn_backlog is needed since he's using syncookies). When creating a new connection every 1ms it only takes 128ms for the backlog to fill up, which is not that improbable with GC and JIT pauses. Java should be faster than erlang most of the time, but the pauses can kill you if you don't handle them gracefully.
If the benchmark had been about "normal" http requests, I would suggest putting HAProxy in front with a reasonable maxconn - then HAProxy will hold on to the connections until the application starts accepting again.