home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / protocol / kerberos / 1023 < prev    next >
Encoding:
Text File  |  1993-01-23  |  3.2 KB  |  73 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!gatech!destroyer!news.iastate.edu!john
  3. From: john@iastate.edu (John Hascall)
  4. Subject: Re: Scalability issues with Kerberos
  5. Message-ID: <C1BEGK.DKp@news.iastate.edu>
  6. Sender: news@news.iastate.edu (USENET News System)
  7. Organization: Iowa State University, Ames, IA
  8. References: <9301211836.AA14955@shadow.secure.bellcore.com>
  9. Date: Sat, 23 Jan 1993 16:14:43 GMT
  10. Lines: 61
  11.  
  12. lunt@CTT.BELLCORE.COM (Steve Lunt) writes:
  13. }Database dumps and loads (via krb_util, which is used by kprop) are
  14. }slow when the database is that big (apparently order n log n).  But
  15. }ticket requests (kinit) and database updates (kadmin and kpasswd) are
  16. }still very fast (apparently order log n).  Also, the ndbm files get
  17. }really big (I think I tested it on a Sun with 10,000 principals, and
  18. }the file was 5 meg in size), if this is a problem on your system.
  19.  
  20. Our kerberosDB has 12580 principals and is just under 13MB in size
  21. (although ls -l would have you think it was 160MB).  We have close to
  22. 900 client machines and our load in 24hrs (Thursday 4am - Friday 4am)
  23. was:
  24.        Initial Requests:  21901   avg of 0.25 /sec
  25.        APPL Requests:     57532   avg of 0.67 /sec
  26.        New Principals:      169
  27.        Password Changes:     60
  28.  
  29. Although the load isn't constant over 24 hours, it doesn't vary as much
  30. as you might think:
  31.  
  32.                          (Total Requests per Hour)
  33.     7000+           * *
  34.         |           * *       *
  35.     6000+           * *       * *
  36.         |           * * *   * * *
  37.     5000+         * * * * * * * *
  38.         |         * * * * * * * * *
  39.     4000+         * * * * * * * * *
  40.         |---------*-*-*-*-*-*-*-*-*----------------------- average
  41.     3000+       * * * * * * * * * * *
  42.         |       * * * * * * * * * * * *           *
  43.     2000+       * * * * * * * * * * * * * * * *   *
  44.         |     * * * * * * * * * * * * * * * * * * * * * *
  45.     1000+ * * * * * * * * * * * * * * * * * * * * * * * *
  46.         | * * * * * * * * * * * * * * * * * * * * * * * *
  47.        0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  48.           4 5 6 7 8 9 1 1 N 1 2 3 4 5 6 7 8 9 1 1 M 1 2 3
  49.                       0 1                     0 1
  50.  
  51. }A kprop/kpropd that sends only updates is critical for realms that
  52. }have # of principals in the tens of K.  In this case, kdb_util should
  53. }only be used in emergencies.
  54.  
  55. While we also would like to see a more `fully distributed' KDB (for load
  56. sharing, fault tolerance, etc.), it appears not to be critical at our size
  57. -- our little DS2100 keeps up with no problem.
  58.  
  59. One thing we didn't really understand when we brought in Kerberos was that
  60. your slave-kerberos server(s) will basically do nothing almost all of the
  61. time.  As an experiment we tried having some machines use the slave as their
  62. primary server, but it was just too confusing for people who had recently
  63. changed their password (we only kprop every 12hrs).  With a more-or-less
  64. instantaneous master-to-slave propagation scheme you could load balance
  65. between multiple kerberii.
  66.  
  67. John
  68. -- 
  69. John Hascall                   ``An ill-chosen word is the fool's messenger.''
  70. Systems Software Engineer
  71. Project Vincent
  72. Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
  73.