Ticket History #1784: replay cache performance sucks

The performance of our replay cache code is rather poor. Even with a
replay cache held open, it can be rather slow at times. My testing
shows highly variable results, from over 1000 requests processed in a
second to under 40. If an expunge is triggered, the performance gets
really bad.

jik's suggestion of skipping the fsync call might be reasonable, but I
suspect there are other ways to speed it up that reduce actual CPU time
used, without affecting the consistency of the on-disk version.

In my tests (2GHz P4 Linux, 5 minutes, no pre-existing replay cache), this gets
about a 10% speedup adding entries to an already open replay cache.

* rc_dfl.c (alive): Take a timestamp argument instead of the context, and don't
check the current time here. All callers changed to pass in the current time.
(rc_store): Take a timestamp argument. All callers changed to pass in the
current time.


To generate a diff of this commit:



cvs diff -r5.69 -r5.70 krb5/src/lib/krb5/rcache/ChangeLog
cvs diff -r5.42 -r5.43 krb5/src/lib/krb5/rcache/rc_dfl.c