Nailing up TCP connections

Noah Robin noah.robin at
Tue Apr 5 20:46:25 UTC 2016

In my environment, we have a plant of internal recursive servers for our
data center and separate plants of authoritative servers; something like
65-85% of the traffic outbound from our recursive plants (several hundred
queries/sec per client machine) is destined for our authoritative plants. I
ran some quick benchmarks to compare per-query times for TCP-keepalive
queries vs UDP queries:

$ ./ -c 5000
use tcp: 0 / keepalive: 0

Querying for ''
5000 iterations executed
Iterations per second: 615.83
Avg time per iteration: 1623.82 μs

$ ./ -c 5000 --tcp
use tcp: 1 / keepalive: 0

Querying for ''
5000 iterations executed
Iterations per second: 464.90
Avg time per iteration: 2151.01 μs

$ ./ -c 5000 --tcp --keepalive
use tcp: 1 / keepalive: 1

Querying for ''
5000 iterations executed
Iterations per second: 842.70
Avg time per iteration: 1186.67 μs

As you can see, the TCP keep-alive test performs significantly better than
the UDP test (TCP without keep alive is included simply as a reference
point). There are all sorts of variables here (not least of which being I'm
using perl as a client rather than an actual resolver or even something
written in C); consider these numbers very back-of-the-napkin and worthy of
more in-depth testing. I know there's an IETF draft to support TCP
keepalives, but the thought occurred to me that a short-term solution would
be an option to nail up TCP connections to specific IPs. This, along with
an option to specify how many queries should traverse such a connection
before that connection is recycled (something comparable to Apache's '
KeepAlive' and 'MaxKeepAliveRequests' parameter) would be an improvement.

Something like:

  tcp-upstream-keepalive-maxrequests: 10000

Thoughts? Has anyone else looked into this?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unbound-users mailing list