Multithreading the KDC server - a design

Morrison, Wayne wayne.morrison at
Mon Apr 4 14:57:00 EDT 2005

On Monday, April 04, 2005 1:57 PM Sam Hartman [hartmans at] wrote:

> Hi.  I think this comment comes from missing some conte xt from a
> discussion a few weeks ago.  Note that the goal in multi-threading the
> KDC is not to take advantage of multiple CPUs.  The goal is to have
> multiple execution contexts available so that while one execution
> context is waiting for remote database access another execution
> context can be processing a request.
> To date, we have no real world performance complaints about KDCs
> running on moderate single-CPU machines.  I don't mean to imply there
> are no performance concerns on the KDC, simply that they are rare
> enough we have not heard them.

Yes, I did not pass on the discussion context when I asked for comments.  However, I still think Tom's analysis is pertinent.  Even though the goal is for multiple execution contexts and not (primarily) for multiprocessing, is there a good reason to preclude the ability to multiprocess?  Yes, not doing it makes the design a bit less complex, but are we sure that down the road we won't need to take advantage of multiprocessing?  It seems to me that with a relatively small extra effort now, we can leave that option open for the future, rather than requiring a redesign later if we find that it's necessary.  Why create a potential bottleneck if we can avoid it?


More information about the krbdev mailing list