Subject: Suggest SSLSessionCacheTimeout and Cache sizes?

From: Ken Snider <[email-masked]>
Date: Fri, 19 Dec 2003 15:54:55 -0500

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.

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?

Thanks for any assistance with the above.

-- 
Ken Snider

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Geoff Thorpe <[email-masked]>
Date: Fri, 19 Dec 2003 21:49:29 -0500

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.

> 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-modssl&m=102286849318705&w=2

Or searching for "shmcb" in the archives can pull up more recent threads 
too.

Cheers,
Geoff

-- 
Geoff Thorpe
[email-masked]
http://www.geoffthorpe.net/