Nailing up TCP connections

[Noah Robin]

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:


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

Querying for 'www.example.com/A'
============================
5000 iterations executed
Iterations per second: 615.83
Avg time per iteration: 1623.82 μs

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

Querying for 'www.example.com/A'
============================
5000 iterations executed
Iterations per second: 464.90
Avg time per iteration: 2151.01 μs

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

Querying for 'www.example.com/A'
============================
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: 10.1.1.1
  tcp-upstream-keepalive: 10.50.1.64/27
  tcp-upstream-keepalive-maxrequests: 10000


Thoughts? Has anyone else looked into this?

Regards,

Noah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20160405/d98a2f40/attachment.htm>