[NB: I tried to post this to Ralf + the mod_ssl users list a week or two
ago but it apparently failed. I've since subscribed and am retrying this
message.]
---------- Forwarded message ----------
Date: Tue, 21 Nov 2000 11:38:08 -0800 (PST)
From: Geoff Thorpe <[EMAIL PROTECTED]>
To: Ralf S. Engelschall <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: HEADS UP: shmcb & engine
Hi all,
This has to be the slowest response time I've been guilty of for ... well
... quite possibly *ever*. Sorry. I'm not on the mod_ssl list(s) so I have
no idea what (if any) follow up discussion there might have been on all
this.
That cache code was written during my time at C2Net, primarily to address
some intermittent seg-faults we were seeing under high-loads in the
shared-memory cache. The exact cause is still a mystery to me but may be
known to others by now, but it required a certain play between the
cache-size, session expiry times, and a strange timing in the testing. To
reproduce it in a default install required (pretty much) hardware
acceleration and concentrated load-testing ... in other words, to see the
problem in reality would require a vastly increased timeout setting or a
much smaller cache. Or possibly, very bad luck might also do it from time
to time. Also, although I could eventually reproduce this problem on
demand (figuring out how to do so was non-trivial though), I could only do
so on x86 systems - eg. I could not get a sparc compilation to produce the
same breakage at all. This led me to suspect some boundary conditions or
endianess weirdness in the hash library, but I never got beyond vague
suspicions. :-) Perhaps some of you already know what that problem
was/is?
Anyway, the fact that the existing shared memory session cache was also a
bit sluggish at times and had some other performance impurities was a
secondary but important thing we decided to try and nail down at the same
time. There's a few things about that newer cache that are quite relevant
from a design point of view that may not be obvious just from the source.
Unfortunately, the code, any READMEs, and any/all statistics and graphs
etc remain inside C2Net/Redhat somewhere :-) However, the main issues
concerning the existing shared memory cache, and how the new one worked
(and how it attempted to address those issues), are pretty
straight-forward - someone else can go out and grab the necessary stats if
they wish, and I'd happily suggest some tips on doing so. But alas I have
neither the physical nor chronological resources to do it myself.
If this stuff is either well understood/discussed already, or of no
interest to anyone, I won't waste bandwidth talking further. Please
contact me if you want me to babble on. :-) I *really* should have replied
to this ages ago rather than filing it away as I did. *sigh*
Regards,
Geoff
On Mon, 9 Oct 2000, Ralf S. Engelschall wrote:
> On Mon, Oct 09, 2000, David Rees wrote:
>
> > > *) Added new Cyclic Buffer based Shared Memory Session Cache
> > > as ssl_scache_shmcb.c. This was contributed by Geoff Thorpe
> > > <[EMAIL PROTECTED]> and is derived from the "c2shm" variant used
> > > in Stronghold V3. It uses a fixed size cyclic buffer placed over
> > > a shared memory segment for storing SSL session ids. This way it
> > > is even more efficient and faster than the old hash table based
> > > shared memory cache (ssl_scache_shmht.c).
> >
> > Cool, any idea how much this helps SSL performance? I guess I could
> > benchmark it and see for myself. :-)
>
> According to Geoff's tests, it both increases performance and provides
> a more robust and efficient session cache. But I've no numbers at hand,
> although I know that Geoff has numbers (actually graphs). Geoff, can you
> make your benchmarking details for c2shm available to the people?
>
> > Is there any configuration parameters we need to be aware of, or is it a
> > drop in replacement for the current shm session cache?
>
> Oh, good catch: I've do add a little bit of documentation, even if it is
> experimental stuff (which usually has no entries in the user manual).
>
> No it is no replacement, it is an addition. The stuff can be tried by
> building mod_ssl with --enable-rule=SSL_EXPERIMENTAL and then using for
> instance
>
> SSLSessionCache shmcb:/tmp/cache(512000)
>
> The old hash table based shared memory session cache still can be used
> with
>
> SSLSessionCache shm[ht]:/tmp/cache(512000)
>
> Yours,
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
>
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
