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