[bind10-dev] Multicore Auth

[Stephen Morris]

On 15/07/2011 02:15, JINMEI Tatuya / 神明達哉 wrote:
> - One key question is how often we want to be able to reflect changes.
>   If we want to support, say, 1000 dynamic updates / sec and want to
>   make the changes visible "instantly", I can hardly imagine any other
>   approach than multi threads + locking (there may be a clever way to
>   achieve the goal with, e.g., shared memory + multiple processes,
>   still involving very few synchronization overhead, but I have no
>   specific idea right now).  If we can allow some delay in propagating
>   changes so that we can apply a set of changes at once and
>   periodically (e.g., every 30sec), other approaches such as multi
>   process + shared memory image can be a solution.  Do we have any
>   specific goal/requirement regarding this question?

Could we ask the sponsors for their input?

But as a data point, Nominet updates the .co.uk zone via dynamic updates
once a minute.


> - Another thing to be considered is how/whether to share hot spot
>   cache between instances (threads/processes) running on different
>   cores.  I've not fully thought about that, but I suspect we'd end up
>   each instance having separate cache.  That would lead to increase
>   total memory footprint, which may or may not be a big issue.  If
>   it's substantial, we need to consider a nice way to deal with that.

If we were to use some form of receptionist process, that could hash the
qname and route the query to a server process based on result. As each
process then answers queries for 1/n the names, the hotspot cache could
be 1/n the size it would need to be if the process answered queries for
all names in the zone.

Advantages
* Smaller cache size for each server process

Disadvantages
* Extra overhead of a receptionist process and message transfer
* Single point of failure in the receptionist process


Stephen