[2529] in Kerberos
Re: Scalability issues with Kerberos
daemon@ATHENA.MIT.EDU (John Hascall)
Sat Jan 23 11:38:48 1993
Date: Sat, 23 Jan 1993 16:14:43 GMT
From: john@iastate.edu (John Hascall)
To: kerberos@shelby.Stanford.EDU
lunt@CTT.BELLCORE.COM (Steve Lunt) writes:
}Database dumps and loads (via krb_util, which is used by kprop) are
}slow when the database is that big (apparently order n log n). But
}ticket requests (kinit) and database updates (kadmin and kpasswd) are
}still very fast (apparently order log n). Also, the ndbm files get
}really big (I think I tested it on a Sun with 10,000 principals, and
}the file was 5 meg in size), if this is a problem on your system.
Our kerberosDB has 12580 principals and is just under 13MB in size
(although ls -l would have you think it was 160MB). We have close to
900 client machines and our load in 24hrs (Thursday 4am - Friday 4am)
was:
Initial Requests: 21901 avg of 0.25 /sec
APPL Requests: 57532 avg of 0.67 /sec
New Principals: 169
Password Changes: 60
Although the load isn't constant over 24 hours, it doesn't vary as much
as you might think:
(Total Requests per Hour)
7000+ * *
| * * *
6000+ * * * *
| * * * * * *
5000+ * * * * * * * *
| * * * * * * * * *
4000+ * * * * * * * * *
|---------*-*-*-*-*-*-*-*-*----------------------- average
3000+ * * * * * * * * * * *
| * * * * * * * * * * * * *
2000+ * * * * * * * * * * * * * * * * *
| * * * * * * * * * * * * * * * * * * * * * *
1000+ * * * * * * * * * * * * * * * * * * * * * * * *
| * * * * * * * * * * * * * * * * * * * * * * * *
0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
4 5 6 7 8 9 1 1 N 1 2 3 4 5 6 7 8 9 1 1 M 1 2 3
0 1 0 1
}A kprop/kpropd that sends only updates is critical for realms that
}have # of principals in the tens of K. In this case, kdb_util should
}only be used in emergencies.
While we also would like to see a more `fully distributed' KDB (for load
sharing, fault tolerance, etc.), it appears not to be critical at our size
-- our little DS2100 keeps up with no problem.
One thing we didn't really understand when we brought in Kerberos was that
your slave-kerberos server(s) will basically do nothing almost all of the
time. As an experiment we tried having some machines use the slave as their
primary server, but it was just too confusing for people who had recently
changed their password (we only kprop every 12hrs). With a more-or-less
instantaneous master-to-slave propagation scheme you could load balance
between multiple kerberii.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
