[bind10-dev] Receptionist experiment

[JINMEI Tatuya / 神明達哉]

At Thu, 28 Feb 2013 15:06:17 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> I did a little experiment with receptionist approach for #2776. I slightly
> modified auth and put another process in front of it.
[...]
> Anyway, I believe that it is possible to write the receptionist without much
> performance penalty and it seems to me to be the most flexible approach we
> thought about. I'd propose going the receptionist path (there are some
> pros/cons of each approach in git).

As an overall conclusion, if it works reasonably fast, I have no
objection to this proposal.

I have some comments on details:

- I'd like to keep each auth and resolver workable without
  receptionist; ignoring the counter-intuitive benchmark results, the
  additional overhead regarding the receptionist inevitably makes the
  entire throughput lower, and the introduction of the additional
  process and IPC makes the system less stable.  Since the hybrid mode
  of auth and resolver is generally a discouraged operation, I want to
  ensure others can run without it.
- I wonder how it would work for xfrout and DDNS.  auth cannot forward
  the FD to them any more, so this should be done by the receptionist.
  This means the receptionist needs to validate/inspect the incoming
  messages more intensively and also needs to have the ability of
  forwarding the FD.
- What should happen if the query has the RD bit but matches an
  authoritative zone?
- I've not looked into the code, but how does the receptionist
  determine the client addresses to return the answer?  Does it keep a
  state?
- Some of the above seem to suggest the receptionist would have to
  share a non negligible amount of features of auth, so I wonder we
  might want to extract some part of request handling of auth into an
  internal library and share it between them, or even provide the
  receptionist feature as a hook for auth.
- I don't know what the double-m version of recvmmsg and sendmmsg do,
  but if the goal is to exchange multiple memory regions between
  processes at once, normal recvmsg and sendmsg seem to suffice.
- We might want to be more careful about measuring the deviation of RTTs.
- as for the benchmark, I'd make sure the auth server is really busy
  utilizing near-100% CPU time, while queryperf runs with a safety
  margin.  Since queryperf can only use a single core, sometimes that
  can be the bottleneck, not the measurement target.  (Depending on
  the actual machine power) that's often the case at a very high query
  rate like over 100Kqps.  Also, in that sense, I'd rather test a
  single instance of b10-auth; in this context I don't think the total
  performance using multi-core is not of the main concern because
  contention overhead is less likely.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.