Fri Feb 17 00:34:30 UTC 2012
rather broad handwaving terms. If I go ahead and do a BPO compile on
the HP, I'll need to do a -xprofile (iirc) on the Sun.
If I do have the cycles, I'll try to get a quick 8.2.5 on the Sun Box.
> Ahh, okay. Now that it's explained to me, it makes sense.
> Again, this is a notation that I would suggest you may want to
> include in the updated version.
I'll see about adding some discussion.
> > If I had a UE280R I would be more than happy to use it. I have a
> > _number_ of things I would like to run on a 280R :) The Blade 1750 is
> > what I happened to have available to me, and it too is about to pumpkin
> > on me. From what little I do know about the two systems, I would expect
> > the performance of the systems to be about the same.
> For a uniprocessor UE280R, I would expect it to perform about
> the same as a SunBlade system of roughly the same speed. I would be
> more interested in seeing how a multi-processor UE280R fares in those
> calculations, however.
I thought that the Blade 1k and the 280R had the same CEC and the only
"real" difference was the packaging?
> > I only mentioned it tangentially, but the warmup time for bind 8 was
> > much much longer than for bind 9. that suggests there are certain
> > situations where "basic" (perhaps uncached) lookups would have higher
> > throughput on bind 9 but i'm not quite sure how to go about
> > investigating that.
> Your testing results of the "warm-up" time for BIND 8 is very
> My own testing indicates that BIND 8 seems to provide the
> initial answer directly from the external response, and it then
> stuffs a copy of the answer into the cache. This means that the
> initial response is usually faster than succeeding cached responses,
> assuming that the authoritative nameserver is fast and close by.
> Contrariwise, BIND 9 seems to stuff the answer into the cache
> and then provide the answer to the original questioner out of the
> cache, meaning that it's usually slower on the initial response and
> faster on the cached responses. I believe that this difference in
> behaviour has been confirmed on this mailing list.
I was talking more in terms of throughput while loading the cache, not
the response time of individual responses. Here BIND9 named has an
advantage in that it can service requests that may have already hit
the cache while some requests are being served by the remote. Also, it
appears that the BIND9 named can have multiple requests outstanding to
that remote, which helps with what I think you are talking about
Once everything is cached though, BIND8 named's path length advantage
At least that is what it looks like from the outside.
More information about the bind-workers