BIND 9.4.1 performance on FreeBSD 6.2 vs. 7.0

[Kris Kennaway]

I have been benchmarking BIND 9.4.1 recursive query performance on an
8-core opteron, using the resperf utility (dns/dnsperf in ports).  The
query data set was taken from www.freebsd.org's httpd-access.log with
some of the highly aggressive robot IP addresses pruned out (to avoid
huge numbers of repeated queries against a small subset of addresses,
which would skew the results).

Testing was done over a broadcom gigabit ethernet cable connected
back-to-back between two identical machines.  named was restarted in
between tests to flush the cache.  resperf is designed to slowly
increase the query rate over a period of 60 seconds, up to a maximum
query rate, to determine the point at which the server starts to fall
behind on answering queries.  To more accurately measure this point,
in each case I tuned the maximum query rate so that the server fell
behind after around 50 seconds of load.

7.0 was used with up-to-date CVS sources and the SCHED_SMP (enhanced
SMP) scheduler, which is not yet committed but for which patches have
been posted by Jeff Roberson.  Actually this did not make much
difference compared to ULE on this workload, although I didn't graph
ULE.  BIND 9.4.1 from the base system was used for the threaded
version, and the bind94 port with threads disabled for comparison.
All debugging was disabled.

6.2 was used from CVS with libthr and the 4BSD scheduler (ULE 1.0 is
broken in 6.x).  In addition I also tested a previously posted patch
from rwatson that may be found here:

  www.watson.org/~robert/freebsd/netperf/20070311-sosend_dgram.diff

The results show several interesting things:

  http://obsecurity.dyndns.org/bind-resperf.png

Firstly, 7.0 beats 6.2 across the board, and has about 60% higher peak
performance.  BIND does not scale beyond 4 worker threads, but this
appears to be due to high contention on pthread mutexes in userland,
i.e. a BIND design problem rather than a FreeBSD kernel problem.
There is moderate UDP contention that, if it can be optimized, might
increase peak performance but is not likely to improve scaling.  For
now it appears that BIND 9.4 does not scale to >4 CPUs.

FreeBSD 6.2 seems to have at least two major performance bottlenecks,
due to file descriptor locking, and poor scaling of the old sx lock
implementation (both have been fixed in 7.0).  I actually don't know
what is using the sx locks so heavily in 6.2, there does not appear to
be an analogue on the 7.0 lock profile.  There are other optimizations
in 7.0 that are probably responsible for a smaller part of the
difference.

Robert's patch gives a modest boost to 6.2 at light concurrency but is
swamped by the other scaling problems at high load.  The graph should
not be interpreted as showing that this patch performs worse at high
load; the variance is so enormous that it is easily consistent with
the CVS data.

It would be interesting to test BIND performance when acting as an
authoritative server, which probably has very different performance
characteristics; the difficulty there is getting access to a suitably
interesting and representative zone file and query data.

Kris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-smp/attachments/20070614/c4b0d16e/attachment.pgp