slow SDB queries

Rob Butler crodster2k at
Tue Oct 26 18:51:55 UTC 2004

Hey Tony,

If your build of Bind supports threading it is
possible to start more than 1 thread per cpu with a
command line switch.  The exact switch escapes my
memory at the moment, but look at the Bind Admin
manual and you'll find it quickly.

What's important above is the "IF your build of Bind
supports threading".  Many of the platforms Bind runs
on do not support threading at all, and on many that
do support threading Bind is built by default without
threading support.  So first you need to determine if
your copy of Bind was built with threading support or

Also, SDB interface code itself does not do any sort
of caching, and most of the driver's are syncronous,
meaning they wait for a response from one query before
beginning the processing of the next query.  So if you
have a slow backend Bind's responses will be slowed as
a result.

Instead of using SDB you may want to look at DLZ.

It can do everything SDB does, and more.  By design
SDB allows you to add and remove host entries from a
zone by adding/removing host entries from a database. 
SDB does NOT allow for adding or removing zones
(domains) though, because to add a new zone (domain)
you need to add a new SDB entry to the Bind config

DLZ however allows you to add/remove host entries from
a zone (domain) AND to add/remove zones (domains) too,
by simply updating the database.  DLZ also supports a
wide variety of DB backends including MySQL,
PostgreSQL, ODBC, LDAP and Berkeley DB.  This allows a
great deal of flexibility in setting up your Bind-DLZ

The most performant DB backend is Berkeley DB (BDB). 
On my test system, an un-modified Bind that stores
everything in RAM can serve 16,108 Queries Per Second
(QPS).  The Berkeley DB HPT backend can support 5325
QPS,  9164 QPS, or up to 12,050 QPS depending upon
which "mode" you use Berkeley DB in.  See the DLZ
website for more info on its Berkeley DB "modes" and
the performance #'s for other database backends.

Because DLZ is so flexible, you can probably get it up
and running with an existing SQL DB of DNS data in a
few hours, and that will give you ok performance
initially.  Then you can build a heterogenous database
replication solution (as described on the DLZ best
practices page) and move up to using the BDB-HPT
backend to get the speed, while still using an SQL
backend of easy data management.

Hope this helps you out.


--- Tony Finch <dot at> wrote:

> How does Bind's SDB API handle slow backends, e.g.
> which require a lot of
> network latency? I see that it allows a backend to
> declare that it is
> thread safe, but Bind 9 (by default) only starts one
> thread per CPU and
> this is not enough concurrency. Will Bind start up
> more threads if
> necessary?
> What if two queries come in for the same SDB domain
> in quick succession,
> so that the response to the first is not available
> when the second
> arrives? Will the second query stall so that it can
> re-use the result from
> the first? Or would I have to run a cacheing server
> in front of the master
> server in order to get this behaviour?
> Tony.
> -- 
> f.a.n.finch  <dot at>

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the bind-users mailing list