DNS query performance

[Pieter de Goeje]

On Monday 11 September 2006 21:55, Marcelo Gardini do Amaral wrote:
> I would like to discuss a little bit more about UDP performance. I've
> made some tests and the results may have some value here.
>
> In this test is easy to see that there is something different in the
> FreeBSD 6 branch.
>
> I made a benchmark with bind 9.3.2 (without threads support) and nsd
> 3.0.1 (1 server forked) on a HP Proliant Dual AMD Opteron 2.4GHz among
> FreeBSD 4.11, 6.1 and Linux kernel 2.6.15, all of them for i386
> systems. I used this simple zone file:
>
<snip>
>                    queries per second
>
> OS                 Bind 9.3.2   NSD 3.0.1
> ----               ----         ----
>
> Linux 2.6 SMP      38845        59645
>
> FreeBSD 4.11 SMP   34977        59417
>
> FreeBSD 4.11 UP    33926        59547
>
> FreeBSD 6.1 SMP    14953        15908
>
> FreeBSD 6.1 UP     15516        14752

I did some UDP performance testing on my own and these are my results:

Both systems are running FreeBSD 6.1-STABLE i386, connected using gigabit 
ethernet.

The server is an AMD Athlon64 2Ghz with an onboard sk(4) gbit nic. The server 
program is a simple UDP echo server, collecting various performance data. 
UDP "requests" are handled completely synchronously. It ofcourse differs from 
the DNS server in the sense that is doesn't actually do anything with the 
received data.

The client is an AMD Sempron 1,6Ghz with a cheap re(4) gbit nic which offers 
no interrupt moderation. The client program forks into a part that sends 
packets as fast as possible to the server and a part that receives echo'ed 
packets from the server. The client is thus capable of doing 
asynchronous "requests". For these tests the client sent 1000000 packets.

Packet Size	Queries/Second	Loss	Total Bandwidth
Bytes					%	10^6 bits/sec
100		57348		0.5	92
200		44873		0.5	144
300		39117		0.4	198
400		35672		0.4	228
1000		27124		0.4	434

Also note that the client was using 100% cpu during the tests. The server was 
approx. 50% idle, using most (28%) cpu in the interrupt handlers, leaving in 
in my opinion enough room for the actual data processing.

My conclusion: there's definately something wrong with your setup. Maybe you 
could try a different NIC to see if the performance issues are driver 
related.

- Pieter de Goeje