home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / kerberos / 1026 < prev    next >
Encoding:
Text File  |  1993-01-24  |  2.4 KB  |  61 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!news.iastate.edu!john
  3. From: john@iastate.edu (John Hascall)
  4. Subject: Re: Scalability issues with Kerberos
  5. Message-ID: <C1CA8v.AwC@news.iastate.edu>
  6. Sender: news@news.iastate.edu (USENET News System)
  7. Organization: Iowa State University, Ames, IA
  8. References: <9301232242.AA01610@steve-dallas.MIT.EDU>
  9. Date: Sun, 24 Jan 1993 03:41:19 GMT
  10. Lines: 49
  11.  
  12. I wrote:
  13. > Although the load isn't constant over 24 hours, it doesn't vary as much
  14. > as you might think:
  15.  
  16. Marc Horowitz <marc@MIT.EDU> writes:
  17. }I see a peak when 9-5'ers get in in the morning, and another peak when
  18. }students get out of class.  And the fact that students have no
  19. }discernible daily cycle accounts of the 1000+ requests at every hour
  20. }of the day.  I doubt intel would have such a distribution.
  21.  
  22. Well, I did a little more work -- I added code in our Kerberos server to
  23. measure the time from request-arrival to reply-departure.  I'll let
  24. it run Monday for some real data, but here's what the first 6 minutes
  25. of running it this evening gave (yes, another gruesome ascii chart):
  26.  
  27.      90+             *               Time from Request to Reply
  28.        |             *                 (in 256ths of a second)
  29.      80+             *
  30.        |             *
  31.      70+             *
  32.        |             *
  33.  C   60+             *
  34.  o     |             *
  35.  u   50+             *
  36.  n     |             *
  37.  t   40+             *
  38.        |           * *
  39.      30+           * *
  40.        |           * *
  41.      20+           * * *
  42.        |           * * *
  43.      10+           * * *
  44.        |           * * *           * * *   * * *
  45.       0+-*-*-*-*-*-+-+-+-*-*-*-*-*-+-+-+-*-+-+-+-*-*-*-*-*-*-*-*-*-*-*-*-*-
  46.          0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3
  47.                              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
  48.  
  49. As you can see, it generally takes our server (an 8MB DS2100 [~8 Specmarks]
  50. with a not-very-fast RZ55 disk) about 6/256 (0.023) sec to service a request.
  51. One might hypothesize that using a modern workstation as a Kserver you should
  52. be able to handle more than 100 requests per second.  I suppose if you needed
  53. more oomph, you could rewrite the server to be multi-threaded (*shudder*).
  54.  
  55. John
  56. -- 
  57. John Hascall                   ``An ill-chosen word is the fool's messenger.''
  58. Systems Software Engineer
  59. Project Vincent
  60. Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
  61.