I've been contacted to evaluate NSD performance and I've identified a little stangeness in the TCP chatter with NSD. NSD always sends the two byte response size as a separate TCP packet (causing the requestor to send a separate ACK) to the main body of the request. You might Expect a TCP DNS request (omitting the possible UDP request that fails) to go something like: SYN --> <-- SYN,ACK ACK --> DNS QRY --> <-- ACK <-- DNS RSP ACK --> <-- FIN, ACK FIN, ACK --> ... plus or minus the optimization of the ACK's with data (which seems to require that you send(2) before your host receives the first ACK). But NSD always does the following: SYN --> <-- SYN,ACK ACK --> DNS QRY --> <-- ACK <-- DNS length (2 bytes) ACK --> <-- DNS RSP ACK --> <-- FIN, ACK FIN, ACK --> Here's a very brief binary dump of the above conversation: -------------- next part -------------- A non-text attachment was scrubbed... Name: tcpdnsqry.dump Type: application/octet-stream Size: 1064 bytes Desc: not available URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20071108/becb4b84/attachment.obj> -------------- next part -------------- Dave. -- ===========================================================================|David Gilbert, Independent Contractor. | Two things can be | |Mail: dave at daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
On Thu, 8 Nov 2007, nsd at dclg.ca wrote:> NSD always sends the two byte response size as a separate TCP packet > (causing the requestor to send a separate ACK) to the main body of the > request.I reported this in May 2006. Found in nsd-3.0.6/doc/TODO: - From Aaron Hopkins: write tcp length and tcp data in one write operation, instead of multiple calls to write. Avoids Nagle algo delay in this case. preallocate 2 bytes in front of buffer to put them into. There are a few other performance-related things I reported at the same time still in the TODO that you might be interested in. -- Aaron
On Fri, 9 Nov 2007, David Gilbert wrote:> I'd like to have a look at this patch. Maybe the patch can be worked > ina more acceptable manner. My client is very concerned about TCP > performance because of DNSSEC being on the horizon.I didn't provide a patch for the extra round-trip per TCP answer problem. The patch http://ftp.die.net/pub/nsd/nsd-3.0.2-fewerselects-nonblocking.patch solved two other problems: - The use of blocking sockets in a nsd had some funky race conditions that could've resulted in the server freezing or the extra servers started by the -N flag not being used. This has been fixed in newer NSDs. - Only one request is processed per socket per select(). And select() is kind of expensive, particularly when you start handling more sockets (like lots of TCP sockets open). Wrapping a loop around the UDP recvfrom() allows us to amortize the cost of the select() over many requests, leading to a 23% throughput improvement in my tests. (This will obviously vary with the hardware, OS, etc.) The downside is that if it concentrates on one socket, it can starve others at least briefly. The current version of the patch limits this to 100 requests, which at 50000 requests/sec works out to up to 2ms of extra latency for the other sockets. -- Aaron