Andrew Cobaugh writes:
> Also currently using it to demonstrate how much faster MIT Kerberos is
> compared to AD, even when not using workers (on modern-ish CPUs, without
> workers enabled krb5kdc can do ~4000 rps. I can share more details if
> folks are interested).
Ah, good, I'm glad my 100 qp
On Mon, Apr 16, 2018 at 5:41 PM, Russ Allbery wrote:
> Sergei Gerasenko writes:
>
> > Will keeping an access log slow me down much, do you know?
>
> Yes, you may want to tune syslog or whatever you're using for your KDC
> logging, although MIT is a lot better than Heimdal in that regard (Heimdal
Sergei Gerasenko writes:
> Will keeping an access log slow me down much, do you know?
Yes, you may want to tune syslog or whatever you're using for your KDC
logging, although MIT is a lot better than Heimdal in that regard (Heimdal
is very verbose). I generally disabled sync to disk on the sysl
> Oh, no problem -- just be aware that they're being answered by someone who
> hasn't run large-scale KDCs in about four years, so some of my information
> is stale. :)
Still very valuable since I haven’t been able to find answers to any of these
questions elsewhere.
> If you're doing default K
Sergei Gerasenko writes:
> Since I don’t know too much about the KDC architecture, sorry for the
> dilettante questions.
Oh, no problem -- just be aware that they're being answered by someone who
hasn't run large-scale KDCs in about four years, so some of my information
is stale. :)
>> It's un
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
Sergei Gerasenko writes:
> Thanks for the quick response, Russ. Let’s say I run 1 worker
> process. How many clients can that sustain in the worst case scenario of
> all the clients trying to get a ticket? I need some way to quantify
> this. As for failover, I am planning to deploy a standby node