"Nicolas Williams" <[EMAIL PROTECTED]> writes: > Recap: "krsh host date" for 1,000 hosts, 20 at a time; by the time the > ccache grows to half its eventual size the overhead of searching > through the ccache swamps the overhead of the TGS exchange and
Wow. I knew we had some bogus stuff in some of our I/O code, but didn't realize it was so serious. > This patch fixes the problem. It unsets the KRB5_TC_OPENCLOSE ccache > flag during cred retrieval, thus causing each krsh/ssh/ftp/whatever > process to run the ccache cred search to completion with one > open/lock/close cycle, rather than one cycle per-ccache entry. > > Alternatively lib/krb5/krb/get_cred.c could be patched to bracket the > call to the cred retrieval function with calls to krb5_cc_get_flags() to > unset, then set the KRB5_TC_OPENCLOSE flag. Maybe. I'm not sure that > krb5_cc_start_seq_get() would work correctly if the ccache it's called > with is closed and has the KRB5_TC_OPENCLOSE flag unset. If the ccache is passed in, I think the flag state should be restored at the end to the way the caller might have set it. But I think cc_retr.c is the right place for temporarily overriding the one flag. So is performance acceptable at 1000 entries now, or should we look at a db2 ccache format? :-) Ken ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
