[bind10-dev] Thinking aloud: Multi-CPU auth

[Michal 'vorner' Vaner]

Hello

I did some thinking in the morning before getting up and I would like to share
it with the rest. It might be nonsense (after all, it is morning), but it might
turn out it would provoke some useful discussion. It's not a proposal of any
kind.

The first idea is how to use all available CPUs for the auth server. Currently
there's only one running and it is single-thread, so it does not use the power
of the rest of the system.

First, classic, way to solve the problem would be to have threads. But the code
in auth is not thread safe and we would have to make it so, which would be a lot
of work.

Another one is using processes and there I see more possible ways:

First, assume we already have the socket creator. The creator (or boss) could
cache opened sockets, so it would be possible to provide them to multiple
processes. Then, boss could just start multiple auth processes and be happy.

Second, assume we have a receptionist (I still think it might be useful to have
it, see next email). Then boss could start multiple auth processes, each one
would bind a different port (any random one provided by OS would be fine) and
reported itself to the receptionist. The receptionist could guess and balance
the load between them.

Third, assume the OS has fork (I heard there are systems that lack that
powerful tool, though). Auth could start, load all the configuration, data (in
case of in-memory data source), bind the sockets and then fork as many times as
needed (leaving the parent do nothing). In case the configuration changed, the
parent would reload it, kill all the children and fork them again (could do it
one by one, so we don't go completely dead). The advantage I see here is both
the simplicity and the fact that the in-memory data are there only once, shared
between the processes.


All three of them have slight problems with updating data. If we have some kind
of SQLish data source, then it will probably take care of the updates, locking
and stuff all by itself. But with the in-memory one, everyone has its own copy.
So we either need to signal everyone else, or have it somehow shared. And I'm
not sure we can have a shared lock on shared memory (because we want concurrent
reads as much as possible). Another way would be that, in case of forking, the
parent would do the updates and then restart the children (if there were many
changes, it would have to be limited in some way, for example no more often than
once every 5 minutes).

Do the ideas make some sense? Improvements and simplifications welcome ;-).

Have a nice day

-- 
Commenting perl code is useless. You have to fully parse it anyway to find comments.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101218/52d94125/attachment.bin>