BIND 9.x caching Performance under heavy loads

[Rick Jones]

Jim Reid <jim at rfc1035.com> wrote:
> Whether it's fast hardware or not doesn't matter. What you're saying
> is that CPU utilisation increases and throughout drops over time,
> right? Well, there could be lots of reasons for that. See below and
> my previous posting on this thread. You can expect this kind of
> behaviour if you're making the name server do more work by
> arbitrarily constraining the size of the cache. Which you're more or
> less admitted.  I paraphrase: "when we make the cache smaller, the
> server falls over more quickly.

A question about that - when you say the server does more work because
its cache has been constraind, you mean it has to go-out and find
results that it might have otherwise cached right?

If that is the case, I would have expected to see the CPU utilization
_decrease_ over time until the cache was filled, the reason being that
when the server first started, it had nothing in cache, and so would
have to do more work on average for each query.

That is if we can ass-u-me that the query rate held fixed.  Perhaps
that is not a good assumption.

As the cache filled, the server would not have to go-out as often and
that should yield a CPU util benefit yes?  Unless I suppose that there
is some point where searching the cache takes more CPU cycles than
simply passing the buck to another server... _that_ could certainly
explain increasing CPU utilization over time - as you alluded later -
longer and longer chains of various types.

I would then expect some sort of "smilely face" CPU utilization graph
- with peaks at either end and a low-point in the middle.

> What happens when you let the name server's cache grow without limit?

That sounds like a very interesting question.

rick jones
-- 
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...