On Tue, Aug 14, 2012 at 3:53 AM, Chris Hecker <[email protected]> wrote: > I have a pretty old centos machine, it's a dual core P4 2.8ghz with 1gb > of ram, running krb5 1.9.x with and openldap backend. I'm using > Authen::Krb5::Admin to make a bunch (5000 right now) of princs, and the > performance on this machine is about 10 princs created per second, with > kadmind at 46% cpu, with slapd at 6%. > > Does this performance sound right for this level of machine? Would it > be much faster using libkadm5 in c? Should I be getting hundreds of > anks/sec or something?
Greg points to string2key() as the primary problem here, and I agree. The AES string2key is specifically intended to go slow for good reasons (namely, to defend against dictionary attacks). (Of course, the AES string2key is not memory-hard, and we should be using FAST w/ anon PKINIT or other armor tickets... but anyways.) For -randkey the limiting factor will be disk random I/O performance, particularly fsyn() performance. You'll probably top out at ~100 fsync()s per-second. The db2 backend requires about 2 fsync()s per-write operation. I don't know how many slapd requires. > Basically, I'm just looking for a ballpark estimate from somebody with a > clue of whether I'd get much out of optimizing this? > > The anks are all happening in a single thread, so they're serialized to > the KDC right now. Code snippet is below. While fsync(2) is slow and the limiting factor for -randkey, multiple threads can call fsync(2) simultaneously and result in higher rates of fsync(2)s, BUT, the db2 backend will lock out all other writers, so this doesn't help you for -randkey. Multi-threading will likely help if you have CPUs to spare because the write-locking happens after the string2key operation. Nico -- ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
