[17555] in Kerberos_V5_Development
Re: KDC performance test - lookaside cache impact, testing framework
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Apr 5 17:52:15 2012
Message-ID: <4F7E1404.7000503@mit.edu>
Date: Thu, 05 Apr 2012 17:52:04 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Tom Yu <tlyu@mit.edu>
In-Reply-To: <ldvvcldhow3.fsf@cathode-dark-space.mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 04/05/2012 05:03 PM, Tom Yu wrote:
> Various developers have suspected that the lookaside cache can be a
> performance bottleneck under some circumstances. Your tests would
> seem to confirm that. It would be useful to do experiments to
> discover if there are ever any cases where the lookaside cache
> actually helps performance.
Probably not with its current design. If a KDC gets loaded enough that
it starts taking longer than a second to process requests, clients will
start retransmitting requests. A lookaside cache could avoid the cost
of processing the retransmitted requests, saving several DB lookups and
cryptographic operations.
However, the current lookaside cache is a linked list. If the KDC is
loaded enough to take almost a full second to answer a request, there
are likely to be hundreds or thousands of entries in the cache.
Searching a linked list of that size will probably take longer than
processing a request--and, of course, that cost is paid for every
request, not just the retransmits.
It would be a fairly simple matter to make a hash table for the
lookaside cache, which should reduce its cost to much less than the cost
of processing a request, making it potentially worthwhile.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
