rough estimate of kadmin addprinc performance?

[Chris Hecker]

> The expensive part of this is probably AES string-to-key, which is 
> intentionally slow (4096 iterations of SHA-1). You should be able to 
> make it go about twice as fast by changing supported_enctypes (in
> the kdc.conf libdefaults section) to include only one of the two AES
> enctypes.

I already only have one enctype allowed on this KDC:

 default_tkt_enctypes = aes256-cts-hmac-sha1-96
 default_tgs_enctypes = aes256-cts-hmac-sha1-96
 permitted_enctypes = aes256-cts-hmac-sha1-96

I just tested creation with randkey for the sake of completeness (I need
the passwords), and yeah, it looks like this:

CPU
11%       slapd
4%       kadmind

but, slapd is 97% DSK, so I guess it's the fsync's.  It's basically the
same speed (10 ank/sec), which makes sense, since the previous test with
passwords wasn't 100% on the CPU, so it was disk bound as well on ldap.

Deletes are also 10/sec.

Chris




On 2012/08/14 09:00, Greg Hudson wrote:
> On 08/14/2012 04:53 AM, Chris Hecker wrote:
>> 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?
> 
> The expensive part of this is probably AES string-to-key, which is
> intentionally slow (4096 iterations of SHA-1).  You should be able to
> make it go about twice as fast by changing supported_enctypes (in the
> kdc.conf libdefaults section) to include only one of the two AES enctypes.
> 
> You could also try to use more CPU cores by using multiple simultaneous
> kadmin.local processes, but they might trip over each other trying to
> lock the DB (because our DB2 locking isn't very good).
> 
> If you aren't actually trying to set these to valid passwords, you could
> use addprinc -randkey which should be much faster (in that it does no
> string-to-key operations).  But based on your code snippet, it sounds
> like you do want the principals to have valid initial passwords, in
> which case the string-to-key operations are unavoidable.
> 
>