Benchmark

Introduction

Client and server are directly connected through a CAT6 cable on a dedicated gigabit interface.
The idea is to count how many packets the server can handle while minimising the "external" factors. Therefore, no switch or other hardware is placed between the sender and receiver.

Details of the test

Sender sends queries from a pcap file using tcpreplay at various speeds
Queries are mostly www.*.eu A queries (most likely NXDOMAIN or NS delegation answer)
No DNSSEC

Machine specifications

Sender

Server: HP ProLiant DL160 G5
CPU: 2x Quad core (Intel(R) Xeon(R) CPU E5405 @ 2.00GHz)
Memory: 4x 4GiB DDR2 (FB-DIMM DDR2 FB-DIMM Synchronous 667 MHz (1.5 ns))
NIC: Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express
OS: Ubuntu 12.04 kernel 3.2.0 (minimal server install)

Receiver

Server: Supermicro X8DTU
CPU: 2x Quad core HT enabled (Intel(R) Xeon(R) CPU L5630 @ 2.13GHz)
Memory: 6x 8GiB (DIMM DDR-3-1333 1066 MHz (0.9 ns))
NIC: Intel Corporation 82576 Gigabit Network Connection
OS: Ubuntu 12.04 minimal server install or FreeBSD 8.2

Procedure

A single pcap file with 6 000 000 UDP DNS query packets was created. We used tcpreplay on the client to send a number of packets to the server at a predefined rate. We calculated the reply rate by multiplying the reply ratio (answers recieved/queries sent) with the send rate. E.g. a send ratio of 100Kqps (100 000 queries per second) and a reply ratio of 80% would result in 80Kaps (80 000 answers per second).

The candidates

Here you can find the results of the benchmark tests between four different DNS implementations:

Yadifa-1.0.0
Nsd-3.2.10
Knot-1.0.5
Bind-9.9.1

These four bar charts show the CPU load time and the zone memory usage for YADIFA, Bind and NSD.
The CPU load time graphs show the time the CPU needs to load the .eu and .com zones. Memory usage refers to the amount of RAM used once the zone has been fully loaded. The build time is the time required to compile the zone file for NSD.