Performance issues with deadwood

[Sam Trenholme]

> and finally I ran another test using namebench ( http://code.google.com/p/namebench/ ), please see results attached. ( I don' t know if the pages will render properly to you.  )

Thanks for the pointer.  I ran namebench myself and got some really
good results against the latest Deadwood snapshot (see below)

> Deadwood:
>
> Avg (ms)        =       691.34
> Min             =       0.39
> Max             =       7,118.85
> Err             =       8
> NoAns   =       52

I just ran namebench 1.3.1 myself against deadwood-H-20100908-2,
running 250 queries.  249 of the queries were answered within the
first 3.5 seconds after sending the query; the one query that wasn’t
answered resolved just fine when I asked Deadwood the query after
running namebench.  The average response time was 302ms.

Compared to Unbound 1.4.6, Deadwood is doing a lot better; Unbound
missed 54 out of 250 queries and took on average 365ms to answer the
queries it was able to answer.

To be fair to Unbound, Deadwood, unlike Unbound, has a persistent
cache (stored to a file between Deadwood sessions; note that this
needs to be set up in CentOS Linux) and wasn’t “started cold” when
running this test.  I, however, still contend it was a fair benchmark:
Since Unbound does *not* have a persistent cache but Deadwood does,
Deadwood will be started with no cache much less frequently than
Unbound will be.

I much prefer namebench over Gibson’s tool; namebench gives out a
verbose log file with the names of every hostname queried for and the
response time needed to query the host name in question.  In addition,
the tool is open-source, so it is possible to add tests, such as
Gibson’s <<random hostname>>.<<known domain with wildcard record>>
test, if needed.

At this point, it looks like Deadwood’s performance is comparable to
other DNS servers.  While Deadwood is a bit slower before having a
cache, this is more than compensated for by Deadwood’s persistent
cache.  I have fixed the bug causing most of Deadwood’s slowdown
people saw before.

In other news, this morning I rewrote the code that creates a random
add_constant for Deadwood’s core hashing algorithm to get its entropy
before loading the mararc file.  My plan today is to finish up writing
the code (use the timestamp to get more entropy and update the
documentation) and then to release Deadwood-2.9.07 today or tomorrow.

- Sam

Note: I am looking for work.  Please send me a private email if you
have something for my skill set (writing a fully functional recursive
DNS server in C).

Note also: Don’t email me personally any MaraDNS support concerns or
bug reports; post your concern to the mailing list.  Otherwise, I
*will* ask you for money.