[1379] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: "benchmark" numbers not so bad after all

daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Jul 3 16:25:28 1996

Date: Wed, 3 Jul 1996 16:25:17 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Donald T. Davis" <don@cam.ov.com>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Donald T. Davis's message of Wed, 03 Jul 1996 16:04:02 -0400,
	<199607032004.QAA26666@gza-client1.cam.ov.com>

   Cc: krbdev@MIT.EDU
   Date: Wed, 03 Jul 1996 16:04:02 -0400
   From: "Donald T. Davis" <don@cam.ov.com>

   i would caution you all, though, against generalizing from mit's low
   performance needs. performance matters most during load peaks, but
   mit's load peaks are probably much easier to handle than a large
   corporation's peaks would be.  richard could probably tell us
   something about what it's like when 1000 people have to log in at
   9:00 am sharp.

Yes, but isn't that done by having a small number of low level employees
run around to all of the workstations and typing the trader's password
into their computer?  After all, traders make $$$ millions of profit for
the company, and so they can't be bothered with entering a password.  :-)

Seriously, if a 1000 people login over a five minute period, that
spreads out the load to 3 requests per second.  And as regimented as
corporate life gets, I very much doubt that you get docked pay for
arriving 10 seconds late to work --- so assuming that all 1000 workers
will be logging in at the same precise moment is not very realistic.

Let's get real --- before modelling how the KDC will deal with 1000
users simultaneously logging in, let's first model how 1000 users will
simultaneously fit through the front door(s) of corporate headquarters
on their way to their offices --- at the same time!

The real bottom line is that while it's good to make the KDC performant,
there's a basic assumption which is that the KDC is not have a very high
transaction rate.  While we may not need to depend on this assumption
(and that's good), I don't believe this assumption has changed.

							- Ted

P.S.  Consider that there are people who want to put public key
operations into the ticket processing path.....

home help back first fref pref prev next nref lref last post