RFC: preauth benchmarking methodology

Dmitri Pal dpal at redhat.com
Fri Jun 3 17:01:52 EDT 2011


On 06/03/2011 04:17 PM, Marcus Watts wrote:
> Sounds to me that initially you should expect the number of
> worker processes to be = to the number of kdc machines.  So,
> w/ 1 machine, any degree of parallelism will give what
> you define as "non-useless" numbers.

You lost me here. Are you talking about worker processes on the KDC or
number of parallel clients that drive the load?

> The deviation of the # of successes -- interesting but is that the only
> deviation you want?  I suspect the distribution of times for successes
> will be interesting, not just the average or even the deviation.

Yes. This would allow to see how changing client timeouts and retries
affects the result.

> Are you using a local db, or ldap?  If you have more than one
> kdc, are they serving requests randomly or is there a preferred
> order, and where is the master in that order?

We are talking about one KDC with local storage (probably LDAP with
LDAPI) but the tests should be independent from the data store.


> Of course, in any "real" environment, kinit's aren't sequentially
> issued; they're issued "at will" independently by a large number
> of independent machines.  So in terms of your test, that means
> "parallelism" is not an integer and actually a function of demand,
> execution time, % of success, and perhaps some measure of
> resource contention.  In a larger environment, or even more an
> environment that updates success / failure, update contention
> will also be important.  Incremental replication may further
> complicate matters.
>

This is true but there is also Monday morning in the big organization
use case. This is probably worst preauth load.
If system can authenticate 50000 users in an say 10 min with failure
rate less then 0.01 then we accomplished the goal.

Another way to look at it is to make sure that KDC does not introduce a
performance bottleneck in comparison to the native solution.
I mean if RSA claims (for example) to support 100 auths/s against a
single Authentication Manager the authentication rate through KDC should
then be within 10% margin i.e. no less 90. There can be a bit longer
response time but not a significantly lower rate.

> When designing your parallel architecture, you should probably
> also consider the possibility of an intentional DOS attack.

Good point but this is an orthogonal goal to the effort.

> Mostly out of curiosity; are you using vm's for this, or real machines?
Probably VMs until someone adopts it as a part of the product
qualification process and dedicates real hardware to it.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the krbdev mailing list