KDC performance test - lookaside cache impact, testing framework

Ken Raeburn raeburn at MIT.EDU
Fri Apr 6 13:36:57 EDT 2012

On Apr 5, 2012, at 17:52, Greg Hudson wrote:
> It would be a fairly simple matter to make a hash table for the
> lookaside cache, which should reduce its cost to much less than the cost
> of processing a request, making it potentially worthwhile.

I'd suggest a btree or something else without the (occasional, but potentially significant) resizing costs.  A fixed-size hash table can reduce the cost by a constant factor without the resizing cost, but changing the cost to log N is likely a bigger win.  And we've got the db2 code sitting around…

Petr's suggestion of reducing STALE_TIME looks like a good one to me, also.  Or perhaps use a heuristic like: If a replay isn't seen in X seconds, assume the client probably got the response, and discard the entry; if there is a replay, there may be a network problem that will cause more replays, so "refresh" the timeout and hang onto the entry until Y seconds after the last replay seen, or until the 5-minute window expires.  (With X and Y chosen based on observed behavior of various clients, assumptions about likely faulty network behavior -- misconfigured firewalls dropping all responses would be one obvious case, several-second latency along a network path might be another -- and perhaps config information like how many KDC addresses in the current realm, since that factors into the retry interval in the MIT client code, at least.)


More information about the krbdev mailing list