On Mon, Jun 10, 2002 at 05:14:38PM -0400, Sam Hartman wrote: > Why? What's wrong with having lots of tickets? Are you actually > running into a performance problem?
Well, I just trussed the kvno command to add a service ticket to a ccache with ~1000 tickets in it. Truss shows a pattern of open()/fcntl(lock)/lseek()/read()s/close() - kvno does this many, many times, then it gets the new ticket and then it appends it to the ccache. I did not expect this behaviour. 20 kvno/ssh/whatever processes running in parallel accessing the same ccache drive the load average up plenty, by almost 20 (lock contention, I imagine). Then I used /usr/proc/bin/ptime, which is like time(1) but more precise, and here's some numbers for kvno (on an otherwise fairly quite system). First I time kvno to fetch a ticket into a small ccache. Then I repeat this command. Next I time kvno to fetch a ticket for the same service into a very large ccache. And then I repeat that command. The large ccache had 1070 service tickets in it. The small ccache had just a TGT in it. % KRB5CCNAME=FILE:/tmp/krb5cc_SMALL ptime kvno host/foo.bar.com [EMAIL PROTECTED]: kvno = 4 real 0.182 user 0.035 sys 0.033 % KRB5CCNAME=FILE:/tmp/krb5cc_SMALL ptime kvno host/foo.bar.com [EMAIL PROTECTED]: kvno = 4 real 0.033 user 0.013 sys 0.015 % KRB5CCNAME=FILE:/tmp/krb5cc_BIG ptime kvno host/foo.bar.com [EMAIL PROTECTED]: kvno = 4 real 0.851 user 0.336 sys 0.509 % KRB5CCNAME=FILE:/tmp/krb5cc_BIG ptime kvno host/foo.bar.com [EMAIL PROTECTED]: kvno = 4 real 0.884 user 0.344 sys 0.531 % So, I think there's a problem here. For this particular use it makes most sense to me to have an option to not store the service tickets in the ccache, at least as a short term solution. Long term it would be nice to have a ccache implementation that involves less lock contention and/or requires less CPU time to use. What I have in mind is a daemon acting as a ccache and the clients accessing the ccache via IPC communication with the daemon. Or an mmap()/SysV shared memory interface, perhaps. I prefer a daemon because then one can put interesting smarts into it, such as knowledge of how/where to prompt the user in order to get new creds when they expire. No, I'm not going to implement any of those longterm suggestions, not anytime soon anyways. I should post a wishlist sometime, but that'd might just prove annoying. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
