KDC performance test - lookaside cache impact, testing framework

[Greg Hudson]

On 05/17/2012 07:59 AM, Petr Spacek wrote:
> I did next performance tests on current KDC and I saw huge performance drop 
> with disable_last_success = false.

I don't see any indication of whether you were using the DB2 or LDAP
back end for this test.  If it's the DB2 back end, one possible culprit
is our lock contention strategy.  Because POSIX doesn't give any way to
obtain a file lock with a timeout, we try to get the lock without
blocking and then sleep for a second (repeated up to five times), which
would obviously be terrible for a KDC performance test.

However, if you're just running a single KDC progress, I'm not sure why
there would be any lock contention.  Perhaps there's something else
making database writes very slow relative to other operations performed
by the KDC.

> -lokaside_cache -preauth_required -last_succ (~ 2850 TGS/sec)
> -lokaside_cache +preauth_required -last_succ (~ 1550 TGS/sec)
> +lokaside_cache -preauth_required -last_succ (~ 255 TGS/sec settled)
> +lokaside_cache +preauth_required -last_succ (~ 150 TGS/sec settled)
> +lokaside_cache +preauth_required +last_succ (~ 25 TGS/sec)

If these are AS requests, it's confusing to write "TGS/sec" in the
results, since TGS is a different type of request.

> Another question: Are there any public patches with proposals for better 
> lookaside cache? I'm curious ... :-)

Not that I'm aware of.  The concept is simple enough: we need a hash
table, or other dictionary implementation faster than O(n), in addition
to the time-ordered linked list (which we need in order to expire old
entries).  A fixed-sized hash table with 4K or so buckets and a fixed
hash function should be enough to mostly eliminate the impact of the
lookaside cache in performance tests.  Something a little more
sophisticated would be required to be resistant to hash table DOS attacks.