Determening the number of clients per KDC

[Sergei Gerasenko]

Hi Russ,

Since I don’t know too much about the KDC architecture, sorry for the dilettante questions.

> It's unfortunately been long enough since I've tested this on a system
> running flat out that I don't remember what qps a KDC can do on modern
> hardware, but I would expect it to at least be in the range of 100 qps.

Is that per worker? 

Speaking of workers, does MIT Kerberos spawn workers as needed (sort of like apache) or is it capped by the `-w` argument? What’s a good number of workers to start with? 70? 500? 1000?

> General rule of thumb for KDCs is that you want at least a master and a
> replica, and there's no reason not to have the replica serve most of the
> traffic (in other words, I wouldn't go with a standby design).  

Ok, to clarify what you mean by the replica serving requests as well, do you mean:

1. Using a VIP that round-robins the requests to the primary and secondary KDC?
2. Or do you mean that half the clients use the master and the other half the slave?
3. Or do you mean that the client itself round-robins between them?

I can only see 2 as a real option because *I think* once a TGT is requested, all TGS requests would need to go to the server that gave the TGT? But I’m rather new to kerberos, so I might be mistaken.

Thanks!!
  Sergei