[38220] in Kerberos
Re: Determening the number of clients per KDC
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Apr 16 11:52:05 2018
From: Russ Allbery <eagle@eyrie.org>
To: Sergei Gerasenko <gerases@gmail.com>
In-Reply-To: <9A950C9B-FB47-45A0-A199-1C08175EEA6C@gmail.com> (Sergei
Gerasenko's message of "Sun, 15 Apr 2018 23:21:51 -0500")
Date: Mon, 16 Apr 2018 08:51:41 -0700
Message-ID: <87d0yz6tf6.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Sergei Gerasenko <gerases@gmail.com> 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.
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.
It's probably constrained by the KDC being single-threaded. Clients
aren't going to generally all try to get a ticket at the same time, due to
ticket caching, so that scales to a lot of clients.
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). Usually I
run at least three KDCs, although the number three is mostly because I
started with kaserver that needed three KDCs for stable Ubik quorum, which
of course isn't a thing with regular KDCs, so I don't know that three is
really better than two.
--
Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
