Do you see a lot of connections in TIME_WAIT? If so I'd just bump up the ephemeral port range via: /proc/sys/net/ipv4/ip_local_port_range (or sysctl -w) But if

Do you see a lot of connections in TIME_WAIT? If so I'd just bump up the ephemeral port range via: /proc/sys/net/ipv4/ip_local_port_range (or sysctl -w) But if you're not getting recycling of TIME_WAIT, you can start to change the reuse/recycle attributes (caveat emptor) with: net.ipv4.tcp_tw_reuse or net.ipv4.tcp_tw_recycle I know I have been benchmarking a servant app by throwing 2048 concurrent connections at it and just bumping up the ephemeral range has been enough for my needs. I tend to run out of socket FD's or just FD issues a lot quicker than ports. Just a thought, but 50-100requests/second doesn't sound like too big of a deal. I did a quick bench of what i have setup and I get this: # wrk --latency -c 128 -t6 http://10.0.2.15:8080/foo/bar/ Running 10s test @ http://10.0.2.15:8080/foo/bar/ 6 threads and 128 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.46ms 5.25ms 137.42ms 90.23% Req/Sec 9.84k 2.13k 19.67k 69.50% Latency Distribution 50% 1.65ms 75% 4.40ms 90% 8.59ms 99% 22.17ms 589624 requests in 10.07s, 476.28MB read Requests/sec: 58560.86 Transfer/sec: 47.30MB Note, this is a static end point so take all these figures with blocks of salt. But by tuning what I said I can have wrk do 2048 concurrent connections reasonably with just a fair increase in overall latency. YMMV