[bind10-dev] resolver performance research, take 2

[Jerry Scharf]

Jinmei,

Once again I must say how much I like the L1 cache idea. The idea of 
stepping the ttl by a few seconds also seems like a good one.


One thing that stands out is the ability to deal with nxdomain as 
efficiently as possible. Some people have reported significant recursive 
server performance improvement by nailing down local fake records to 
prevent upstream queries for common nxdomains.

My guess is that the vast majority of these are queries with predictable 
structure for things where the error is returned by a registry 
controlled authoritative server. Would it make sense to allow the user 
to configure a longer cache time for this case to reduce the upstream 
queries? Would a 12 hour cache on these make a significant difference in 
upstream queries? I bet just doing this for the root, where the real 
world update rate is measured in months/years between additions of new 
TLDs, would help quite a bit.

It's a simple trade of coherence time vs upstream traffic that seems 
appropriate given that there is a fixed update cycle. This becomes 
extremely useful if there was a way for a domain to publish it's next 
time when the addition of a zone may happen. One way this could be done 
would be to add a known record in additional data with a ttl that 
matches the next publication time for the zone (they may need to fuzz 
this a bit to prevent traffic spikes.) One would think this would be a 
benefit to both recursive servers and registry servers traffic.

This is all is just wild speculation that I had when I was working on 
the Trend recursive server.

jerry


On 07/17/2012 12:09 AM, JINMEI Tatuya / 神明達哉 wrote:
> Following the preliminary results I reported before, I've continued
> the research task on high performance resolver implementation.  I used
> the same old data set but this time did more detailed analysis,
> emulating actual server behavior.
>
> It contains various topics and is long, so I dumped my report on wiki:
> http://bind10.isc.org/wiki/ResolverPerformanceResearch
>
> High level summary is:
> - The idea of separate L1 cache now looks even more promising.
> - We might even introduce an optimization skipping any TTL adjustment
>    in that cache
> - Exploiting the TTL difference on different types of RRs may lead to
>    other types of (probably novel) optimization
> - It may be possible to optimize response message handling, exploiting
>    the fact that most of them fall into a small number of simple cases
>
> As we discussed last week, we'll need to suspend this task for now.
> But analysis tool is now ready, so if and when we get newer query data
> we can get the result with them and have some followup discussions.
>
> ---
> JINMEI, Tatuya
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev