rough estimate of kadmin addprinc performance?

[Nico Williams]

On Tue, Aug 14, 2012 at 3:53 AM, Chris Hecker <checker at d6.com> 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
--