Multithreading the KDC server - a design
hartmans at MIT.EDU
Mon Apr 4 15:05:45 EDT 2005
>>>>> "Morrison," == Morrison, Wayne <wayne.morrison at hp.com> writes:
Morrison,> On Monday, April 04, 2005 1:57 PM Sam Hartman
Morrison,> [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.
Morrison,> Yes, I did not pass on the discussion context when I
Morrison,> asked for comments. However, I still think Tom's
Morrison,> analysis is pertinent. Even though the goal is for
Morrison,> multiple execution contexts and not (primarily) for
Morrison,> multiprocessing, is there a good reason to preclude the
Morrison,> ability to multiprocess? Yes, not doing it makes the
Morrison,> design a bit less complex,
Yes. It makes the implementation and initial debugging far easier and does not preclude moving to finer grain locks in the future.
but are we sure that down
Morrison,> the road we won't need to take advantage of
Signs point to yes, but no we are not sure.
It seems to me that with a relatively
Morrison,> small extra effort now, we can leave that option open
Morrison,> for the future, rather than requiring a redesign later
Morrison,> if we find that it's necessary. Why create a potential
Morrison,> bottleneck if we can avoid it?
Your experience designing locking architectures has been less
problematic than mine.
In general I'm familiar with the strategy of creating large locks and
then later replacing them with small locks as needed.
More information about the krbdev