[1353] in Kerberos_V5_Development
kdc performance and rcache
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Jun 27 04:35:26 1996
Date: Thu, 27 Jun 1996 04:35:02 -0400
From: Ken Raeburn <raeburn@cygnus.com>
To: krbdev@MIT.EDU
I wrote a little test program to whack on the KDC as fast as the KDC
can respond, and I've been doing some profiling of the KDC under these
conditions. This program thrashes the database pretty heavily, and
concentrates on fetching additional tickets much more than initial
tickets. When it finishes, it also generates some numbers on server
performance.
We've managed to improve the numbers on our Sun server by nearly a
factor of two (though they're still poor), but a couple of the changes
involve eliminating caches.
Is there any reason the KDC needs an rcache at all? Disabling it
improves the performance on our server, since it no longer needs to
call fsync each time a request comes in. It also makes writing this
kind of profiling program easier. :-)
Also, the lookaside cache seems of marginal value. If the server is
loaded, you don't want to scan a long linked list of all recent
requests, and if it isn't, the cpu time wasted by re-processing the
request probably isn't a big deal. Rewriting the algorithm to
something O(log(n)) might be an improvement too, and could make it
worth keeping, but then again, maybe not. (After fsync, the
linked-list scan got to be high on the cpu-wastage list when I was
whacking on the KDC with my rather abusive test program.)
Unless anyone's got a reason why these caches should be considered
useful, I'll check in the changes to disable them in the KDC (but keep
the implementations intact) next time we merge Cygnus changes into the
MIT tree.
Ken
P.S. FYI, high on the list of CPU use right now are:
* DES (Karn code should improve this)
* DES (it's up high enough it deserves to be listed twice)
* fcntl for database locking (but I've got some ideas to look into)
* malloc/free, partly from googols of krb5_copy_foo calls per request
I'm also going to try shifting the emphasis more towards
initial-ticket requests and see how that affects things.
