[Pdns-users] PowerDNS cannot handle the load?

[Mike Benoit]

On Wed, 2003-04-23 at 16:11, Brad Knowles wrote:
> At 10:23 AM -0700 2003/04/23, Mike Benoit wrote:
> 
> >  Consistent, but how long do they take to startup? BIND takes so long to
> >  startup because it basically pre-caches all the zones (before it starts
> >  serving any even?).
> 
> 	Not true, not for BIND 9 at least.  BIND 9 starts answering 
> queries immediately on startup, at least for the zones that it has 
> loaded so far (obviously, you can't answer for data you don't have).

Thanks for the correction, I wasn't sure about Bind 9. Does Bind 9 load
the zones faster then Bind 8 by chance? I know previous to PDNS, Bind8
couldn't handle the amount of zones we had very well at all. If I recall
correctly Bind8 used to take about an hour to startup on a PIII-866 with
1GB of ram. After some serious hacking, we got it down to 2minutes,
unfortunately PDNS wasn't around at this time.

> 
> >                      PDNS approaches this a different way, and simply
> >  starts serving answers immediately after starting.
> 
> 	PowerDNS may have "started" and trying to answer queries 
> immediately on startup, but like BIND it can't answer for data it 
> hasn't loaded yet.  The issue is how fast can PowerDNS get the data 
> from the back-end database and put that into its cache.

This is true. But I don't think your looking at the whole picture. Lets
take a Bind setup with 10,000 zones, and PDNS with 10,000 in it's SQL
database (or BIND backend, I think it works pretty much the same). Now
assume we know the very last zone that Bind will load, and (though it
doesn't matter) the very last zone in the PDNS backend "database". Start
both name servers, and immediately query for this very last zone. 

How does BIND handle this case? I assume the query will fail. However
PDNS, though the query might take 1-5ms to answer the first time, it
should have no problem doing so.  

> 
> >  I don't think your comparing apples to apples here. Try timing a script
> >  that does this:
> >
> >  start bind
> 
> 	In background.  Don't wait for the start to complete before you 
> start firing queries at it.  You want to look at how it handles 
> queries during startup.

If you don't wait for it to completely start, then you need to track
failed queries and account for these in the test results. This was
partly my point. BIND caches all zones right from the get-go, if you
want to compare apples to apples, put both name servers in the same
"state" and run your test. Either all zones cached, no zones cached, or
"real-world" where queries start coming in immediately after the name
server is started.

> 	Once you've done the queries that will hit all records in all 
> zones, you can test the steady-state performance of both servers, 
> which is what we really care about.
> 	You cause all records in all zones to be loaded (thus causing the 
> cache to be maximized in size) because you don't know, a priori, 
> precisely which records will be asked for in what order in a 
> real-world scenario.  Sure, you can capture a complete list of 
> queries that occur over a given period of time and use that as your 
> test input, but there's nothing to say that the pattern of queries 
> during this period of time is an accurate simulation of future 
> performance.
> 
> 	In the case of BIND, the real-world performance should be no 
> worse than this test shows, assuming the queries are generated with a 
> comparable frequency and latency.  However, in the case of PowerDNS, 
> the real-world performance might actually be better than the 
> benchmark, because you shouldn't be caching all records.

I think you hit the nail on the head here. PDNS will automatically by
means of cache-expiry tune itself to any particular situation. If a zone
gets queried often, it will be fast. If it doesn't, it will be slightly
slower, but still should be more than fast enough. 


-- 
Best Regards,
 
Mike Benoit
NetNation Communications Inc.
Systems Engineer
Tel: 604-684-6892 or 888-983-6600
 ---------------------------------------
 
 Disclaimer: Opinions expressed here are my own and not 
 necessarily those of my employer