Multithreading the KDC server - a design
Nicolas.Williams at sun.com
Mon Apr 4 16:42:21 EDT 2005
On Mon, Apr 04, 2005 at 01:56:54PM -0400, Sam Hartman 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.
Sam, why assume that the DB will require serialized access? Let the DB
serialize access if it cares to.
> 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.
I've observed real-world problems where an MIT KDC running on decent HW
didn't process requests fast enough to prevent client timeouts. As I
recall the problem was not serious but stemmed from having configured
many clients to have the master KDC in their KDC list along with other,
topologically close KDCs. Mostly the problem went unnoticed by users,
which is why I don't think it was serious, but, still.
More information about the krbdev