Multithreading the KDC server - a design
wayne.morrison at hp.com
Mon Apr 4 14:57:00 EDT 2005
On Monday, April 04, 2005 1:57 PM Sam Hartman [hartmans at mit.edu] 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