[bind10-dev] recursor cache requirements - input required

[Jerry Scharf]

Michal,

We are not talking about a log(n) tree here. We are talking about a 
query with 6 labels being unusual. You build the hashes of children at 
each node. With fanouts of at least 50-100 and exceeding 1,000,000, the 
hashes are still quite effective.

As for caching extra data at nodes, its a tradeoff of making things 
faster on one hand and increasing the memory footprint and increasing 
the code complexity on the other.

I once again recommend you make the basic code work first. It is in my 
experience half an order of magnitude harder on the recursive side than 
the authoritative side.

Second, if you look at the people who have made recursive servers go 
fast (Nominum) they didn't do that by looking for percentage gains by 
caching more information at nodes. They did the really hard job of 
making it so it can be efficient on multiprocessor/multicore machines. 
Adding all sorts of extra caching up front makes getting the multiaccess 
and multiupdater cache working that much harder.

jerry

On 12/9/2010 1:56 AM, Michal 'vorner' Vaner wrote:
> Hello
>
> On Wed, Dec 08, 2010 at 11:31:06AM -0800, Jerry Scharf wrote:
>> Getting the answer rrset or an error from cache is simple. You just walk
>> down the logical namespace hierarchy until you find the cache entry.
> I don't like walking down. It kind of enforces using a tree, which is slow.
> Being able to use a hash table would be nice.
>
> Can't it be done by looking up the exact entry, then if it is not there, walking up
> (eating the labels one by one) and looking up the NS rrsets if there's one? And
> having a pointer to authority inside each of the rrset? Or, having some other
> data structure for looking up the nearest known zone cut (because the cache will
> do two kinds of queries - for exact name/rrtype and for nearest known zone cut
> in case we don't have no answer for the first type of query)?
>
> Have a nice day
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101209/730d92fc/attachment.html>