Hi Ken,
On December 19, 2003 03:54 pm, Ken Snider wrote:
Does anyone have any information on shmcb cache sizings? Specifically,
how many bytes per request are taken up in shm for each cache entry?
I'd like to make sure my shm size is sufficient for the Cache Timeouts
I want to use.
The geometry and administrative data in the shared-memory segment create
their own nominal overheads, but for the most part the space taken to
store a session is largely determined by openssl's asn1 encoding of the
corresponding SSL_SESSION object. For a typical ssl session, you'd
expect this to be around 120-150 bytes. OTOH if you use client
certificate verification, things get a bit more serious - ie. the bulk of
the encoded session is a copy of the client-certificate, so this can
easily grow to 1Kb or more. As for the organisation of the cache data, I
can blab on about that - but won't do so unless dared.
Secondly, is there any reason why the SSLSessionCacheTimeout can't be
arbitrarily large (say, an hour)? And at what size (or number of
entries) does the cache size begin to seriously hamper lookups within
the cache itself?
This was a problem with the earlier caching code (shmht) and was part of
my motivation for designing shmcb (though there were numerous other
reasons, bugs and slothful speed being two major ones). Namely, the cache
would essentially block when full and fail to add new sessions until an
expiry-checker would periodically scan over the cache and delete anything
old. This meant you needed to choose cache timeouts carefully to avoid
this situation - because if you're under load and the cache fills, you're
going to be even *more* under load on account of attempted session
resumes resorting to full handshakes more and more often.
shmcb uses a different approach to shmht - if the cache fills (or more
accurately, if the sub-cache corresponding to a session you're trying to
add fills), then sessions are scrolled out of the (sub-)cache until there
is enough room for the new one. Sessions are prematurely expired in order
of their expected expiry time - that's a complicated phrase because it's
not necessarily quite the same thing as the oldest sessions, because
you may be using vhosts that use different expiry times for sessions.
The consequence of this behaviour is that if you have limited shared
memory for the cache and your load is sufficient that sessions generally
get prematurely removed before reaching their specified timeout(s), then
so be it - the effective timeout implicitly adapts to maintain a full
cache and to favour newly added sessions over those that have been there
a while. When the load drops again, this effective timeout grows until
that point where sessions begin to reach their natural expiry time and
are then removed irrespective of cache utilisation. Moreover, the use of
the cyclic buffers, sub-caches, and indexing tricks means that the speed
of cache operations should be pretty constant irrespective of the cache
size or utilisation.
Which is all a rather long-winded way of saying yes to your
Secondly,... question. With shmcb you can choose the timeout according
to security arguments alone, cache size and usage will automatically
remove sessions prematurely when necessary to keep things flowing
nicely, so the timeout is more of an administrative setting that says
if the session is still in the cache after *this* many seconds, I want
it explicitly removed to force any future resume attempts to undergo a
full handshake anyway. The timeout only dictates what happens when the
cache has space to spare.
For more information, this old post linked off to 2 or 3 other posts with
all the run-down on shmcb and associated junk;
http://marc.theaimsgroup.com/?l=apache-modsslm=102286849318705w=2
Or searching for shmcb in the archives can pull up more recent threads
too.
Cheers,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
