KDC performance test - lookaside cache impact, testing framework

[Ken Raeburn]

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.)

Ken