From: Shane Kerr Date: Tue, 19 Feb 2013 13:58:35 +0000 (+0100) Subject: Some starting questions for recursive resolver research. X-Git-Tag: bind10-1.2.0beta1-release~404^2~5 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=edfad4a9bb65049599adaf9cf68baedf7bc072b7;p=thirdparty%2Fkea.git Some starting questions for recursive resolver research. --- diff --git a/doc/design/resolver/01-scaling-across-cores b/doc/design/resolver/01-scaling-across-cores new file mode 100644 index 0000000000..8fc376be5e --- /dev/null +++ b/doc/design/resolver/01-scaling-across-cores @@ -0,0 +1,21 @@ +01-scaling-across-cores + +Introduction +------------ +The general issue is how to insure that the resolver scales. + +Currently resolvers are CPU bound, and it seems likely that both +instructions-per-cycle and CPU frequency will not increase radically, +scaling will need to be across multiple cores. + +How can we best scale a recursive resolver across multiple cores? + +Some possible solutions: + +a. Multiple processes with independent caches +b. Multiple processes with shared cache +c. A mix of independent/shared cache +d. Thread variations of the above + +All of these may be complicated by NUMA architectures (with +faster/slower access to specific RAM). diff --git a/doc/design/resolver/02-mixed-recursive-authority-setup b/doc/design/resolver/02-mixed-recursive-authority-setup new file mode 100644 index 0000000000..84658ef8b4 --- /dev/null +++ b/doc/design/resolver/02-mixed-recursive-authority-setup @@ -0,0 +1,28 @@ +02-mixed-recursive-authority-setup + +Introduction +------------ +Ideally we will run the authoritative server independently of the +recursive resolver. + +We need a way to run both an authoritative and a recursive resolver on +a single platform, listening on the same IP/port. + +We have 3 basic components involved in this mix: + +1. Authoritative zones +2. Cached RRSETs +3. Non-cached information + +There are a number of possible approaches to this: + +a. Make a module that includes all logic. (The BIND 9 module?) +b. Look at authoritative server first, and pass queries to the + recursive component. +c. Make a module that combines authoritative and cache. Queries not + found get passed to a resolver, which also has to update the cache. +d. Have a simple "receptionist" module which knows which zones we are + authoritative for and sends all queries to another daemon. + +Stephen did some modeling work on this already. We need to understand +the latency and throughput implications of any of these approaches. diff --git a/doc/design/resolver/03-cache-algorithm b/doc/design/resolver/03-cache-algorithm new file mode 100644 index 0000000000..42bfa0974d --- /dev/null +++ b/doc/design/resolver/03-cache-algorithm @@ -0,0 +1,22 @@ +03-cache-algorithm + +Introduction +------------ +Cache performance may be important for the resolver. It might not be +critical. We need to research this. + +One key question is: given a specific cache hit rate, how much of an +impact does cache performance have? + +For example, if we have 90% cache hit rate, will we still be spending +most of our time in system calls or in looking things up in our cache? + +There are several ways we can consider figuring this out, including +measuring this in existing resolvers (BIND 9, Unbound) or modeling +with specific values. + +Once we know how critical the cache performance is, we can consider +which algorithm is best for that. If it is very critical, then a +custom algorithm designed for DNS caching makes sense. If it is not, +then we can consider using an STL-based data structure. + diff --git a/doc/design/resolver/README b/doc/design/resolver/README new file mode 100644 index 0000000000..b6e9285405 --- /dev/null +++ b/doc/design/resolver/README @@ -0,0 +1,5 @@ +This directory contains research and design documents for the BIND 10 +resolver reimplementation. + +Each file contains a specific issue and discussion surrounding that +issue.