KDC performance test - lookaside cache impact, testing framework

Roland C. Dowdeswell elric at imrryr.org
Mon Jun 18 11:32:59 EDT 2012


On Mon, Jun 18, 2012 at 11:07:40AM -0400, Greg Hudson wrote:
>

> On 06/18/2012 10:47 AM, Nico Williams wrote:
> > What's the point of the lookaside cache?  A: To avoid re-computing
> > replies to retransmited requests, which might occur in the event that
> > the KDC is much too busy.
> 
> Retransmitted requests can also happen if a KDC needs a few seconds to 
> process a request, e.g. to contact a slow OTP server.  Since we're 
> trying to support that case, I'm (so far) more interested in making the 
> lookaside cache efficient than dropping it.
> 
> And, of course, they can happen when a packet is lost.  Usually that's 
> rare, so maybe that's not important.

In most of the krb5 environments that I've seen, people set up many
slaves and the clients will in general contact the next kdc on the
list rather than retransmitting to the same one.  In this case, a
simple lookaside cache limited to one KDC is unlikely to be terribly
helpful in most use cases.

Given that many OTP services perform lockouts, it seems to me that
(if one can't turn off that rather unhelpful behaviour) perhaps
the solution will have to be a bit more complicated than a per-KDC
lookaside cache.

I agree with Nico that for the old fashioned passwd case that the
lookaside cache is going to save only a tiny bit of processing in
extremely rare cases on a well managed network.  And it's unlikely
to save much even with mild levels of packet loss.  After all, with
10% packet loss and two KDCs, the chance that the same KDC will
get the same UDP req is about 1%.  Seems that you'd have to have
pretty serious amounts of packet loss and not terribly many KDCs
to justify this.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/


More information about the krbdev mailing list