How to prevent very very large ccaches?

[Nicolas Williams]

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
host/foo.bar.com at BAR.COM: kvno = 4

real        0.182
user        0.035
sys         0.033
% KRB5CCNAME=FILE:/tmp/krb5cc_SMALL ptime kvno host/foo.bar.com
host/foo.bar.com at BAR.COM: kvno = 4

real        0.033
user        0.013
sys         0.015
% KRB5CCNAME=FILE:/tmp/krb5cc_BIG ptime kvno host/foo.bar.com
host/foo.bar.com at BAR.COM: kvno = 4

real        0.851
user        0.336
sys         0.509
% KRB5CCNAME=FILE:/tmp/krb5cc_BIG ptime kvno host/foo.bar.com
host/foo.bar.com at BAR.COM: 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.