[bind10-dev] initial memo on recursive server performance research

[Jerry Scharf]

On 07/04/2012 06:47 PM, Likun Zhang wrote:
> Hi Jerry,
>
>> Jerry Scharf
>> Sent: Thursday, July 05, 2012 1:08 AM
>> To: bind10-dev at lists.isc.org
>> Subject: Re: [bind10-dev] initial memo on recursive server performance
>> research
>>
>> Jinmei,
>>
>> On your second point.
>>
>> Would it be possible to do the analysis for the actual cache hit rate
>> rather than just the name appearing? Many of the popular web sites use
>> short ttls (30-300s) for the main target. which reduces the
>> effectiveness of caching.
> Pre-fetch may helps here. the entries in cache will be refetched before they expire, in the last 10s, etc. but if the ttl is too short(less than 10s? we can give a min-ttl to stop it, :) ), it doesn't work.

I would think prefetch will help the larger L2 cache, but unless you add 
a bunch of complexity you will still miss the L1 cache. You would need 
to have the L2 prefill send some kind of message to the L1 cache to let 
it know the cache ttl has changed but nothing else, but the L2 won't 
know exactly which entries are in a given L1 cache. It is probably 
easier to just let the L1 miss and fill it from L2 to start with. 
Prefill still makes the overall query processing a single step process 
and keeps QPS high.

I've not seen many ttls <30s, but people do all sorts of weird things 
with their zones. I think most of the large targets keep them higher 
than 10s just to keep DNS load from being insanely large and increasing 
latency to their sites.

>
>
>> I really like the idea of a fast L1 cache per auth. The idea of an added
>> a hast test/ttl check and L1 cache store to misses in return for not
>> walking the tree/rebuilding the answer for popular queries seems like it
>> would be a big win. All you need to do is fix the ttls and wrapper and
>> it's ready to go. You will have to think a little bit about victim
>> selection when a new cache entry comes in. You would like to victimize
>> entries that have no hits before google.com gets replaced. When you get
>> to views, you will need an L1 per view.
>>
>> I wish I had thought of this when I was working on the trend recursive
>> server. It may be a cheap 20% increase in performance.
>   
> Are you talking about authoritative server here? if not, does recursive server need to support views?

I may be a rare case, but I had a border server that for ran views and 
recursive service. If this was not allowed, I could find other ways to 
solve the problem. This was not on a massively loaded server so not 
having the L1 cache enabled would not have been a problem. It may well 
be that L1 and views have very disjoint sets of users. If you are asking 
whether a recursive server needs to be able to support views in general, 
I have needed that in the past. I might do it differently today and have 
no idea how many people would be impacted by not providing views for 
recursive service. My hunch is that it is more people than you might 
suspect.

All this is just the opinion of an old timer and should not be taken as 
anything more than that. I am also one of the people who pushed BIND 9 
to have views in the first place (you can all hate on me now.)

jerry

>
> Likun
> 　　
>
>