Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Sebastian Schrader
Kea
Commits
edfad4a9
Commit
edfad4a9
authored
Feb 19, 2013
by
Shane Kerr
Committed by
Michal 'vorner' Vaner
Jun 13, 2013
Browse files
Some starting questions for recursive resolver research.
parent
e93ef80d
Changes
4
Hide whitespace changes
Inline
Side-by-side
doc/design/resolver/01-scaling-across-cores
0 → 100644
View file @
edfad4a9
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).
doc/design/resolver/02-mixed-recursive-authority-setup
0 → 100644
View file @
edfad4a9
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.
doc/design/resolver/03-cache-algorithm
0 → 100644
View file @
edfad4a9
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.
doc/design/resolver/README
0 → 100644
View file @
edfad4a9
This directory contains research and design documents for the BIND 10
resolver reimplementation.
Each file contains a specific issue and discussion surrounding that
issue.
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment