Entry

How well does djbdns perform? What are the benchmark statistics?

Mar 3rd, 2003 14:50
Brian Coogan,

A collection of notes from the mailing list shows that dnscache wins 
when compared to Bind by a reasonable margin  -- importantly, logging 
has to be turned off to get full speed.
A point to note here is that raw speed is not everything - dnscache is 
kinder to servers as it limits memory usage (Bind can use large 
amounts of memory quite quickly under some circumstances).  It would 
be worth giving up a small amount of performance for the stability 
this provides - though it turns out you don't have to!  Plus you get 
the other benefits of djbdns such as a much more secure implementation 
and ease of admin.  The figures below vary between being about the 
same speed as Bind to several times faster, depending on the 
circumstances.
Matt Simerson wrote on 26 Apr 01:
"A 3.1 million entry data.cdb file runs to approximately 247MB 
(247911419 bytes). The source data file is 152MB and it takes exactly 
40 seconds to compile the database from the flat file on a FreeBSD 
running Quad Xeon 550MHz with 2GB of RAM. [note the server remains 
available while the new data.cdb file is being built]
Interesting side note to this:
Dnscache stats as of yesterday:  200MB cache full (198123519 bytes). 
In 
5 days of uptime it has processed 1.9 billion (1951598982) queries 
which averages out to 4500 queries per second. The dnscache process 
consistently chews up 45% of one CPU and multilog (-*) eats up 10% of 
another CPU.
Yesterday I made two changes. I bumped the cache size up to 300MB and
restarted dnscache.  I also disabled logging entirely (exec 1>/dev/null
2>&1). Today dnscache is humming along at 30% of one CPU and multilog
obviously is using no CPU."
Matt also found multilog with a stats recipe (-* +'stats *' =/file) 
consumed 8-10% CPU while cat > /dev/null consumed 12-14% of a CPU [26 
Apr 01]
Nate Campi writing on 24 Aug 2020 found:
"BIND9 on a dual-proc UE2 running Solaris 8 (BIND built with 
--enable-threads) could handle only around 100 queries/sec, frequently
stopping resolution for up a minute. This was weird, I'm going to test 
this on other hosts/platforms later.
Vanilla BIND8 (on the same UE2) handled up to 800 queries/sec with 
cached data (stop the test and run it again, so the data is cached), 
not
too shabby overall.
dnscache running on Solaris 8 x86 on a compaq DL360 (1 gig RAM, dual
PIII 800) handles close to 1000 queries/sec with no data cached, and 
this is across a wide area link (DS3)! Plus dnscache uses 3 megs of
memory, while BIND grew to over 150 megs in just the few minutes we ran
the tests. It actually appears that we maxed out the capabilities of
our tests to send the messages, and didn't even max out dnscache's
ability to answer queries."
Most of these people turn off logging, or restrict it to just stats 
lines, to get this sort of performance.
Sam Trenholme, MaraDNS author, did some speed comparisons around 13 
May 
2001 and published the data:
  http://www.maradns.org/speed.comparison.html
Not surprisingly, MaraDNS won :)  (I wouldn't publish data showing my 
code to be slow, would you?? *grin*)  Note that MaraDNS holds all its 
data in memory, whereas tinydns reads it from disk. (not sure whether 
this was actually relevant) No other data was supplied as to whether, 
for instance, dnscache logging was on, but I would suspect it was and 
that dnscache would be about twice as fast with it off.
Matt Simerson did some earlier benchmarking work, during which it 
became clear just how much logging affects the figures.  Djbdns showed 
well against Bind here:
  http://marc.theaimsgroup.com/?l=bind-users&m=99014422707740&w=2
Original figures with logging turned on:
  http://marc.theaimsgroup.com/?l=djbdns&m=99012787423933&w=2
(you can follow the thread via marc for more discussion)
In Feb 2002, Matt also wrote about moving from Bind to djbdns.  In 
summary,  Matt found that djbdns was able to serve requests at 4,000-
6,0000 per second without loss, whereas Bind 8 running on the same 
servers had been dropping approximately 30% of packets:
  http://marc.theaimsgroup.com/?t=101406763600002&r=1&w=2
  (this is a link to a discussion, see Matt's posting near top)
Sami Farin also writes in Feb 2003 that dnscache speed can be 
increased about 28% over "exec cat > /dev/null" by removing the 
logging code (avoid this unless you are huge AND desperate!!):
   http://marc.theaimsgroup.com/?l=djbdns&m=104639595501237&w=2
Dan's FAQ comments re tinydns speed:
  http://cr.yp.to/djbdns/faq/tinydns.html#speed
Dan's FAQ comments re dnscache speed:
  http://cr.yp.to/djbdns/faq/cache.html#speed