In article <35D94213.E0927886@multithread.co.uk> you wrote:
>> >[...]
>> > Also, I just grabbed 1.3.1/1.22 and was wondering how gcache was doing
>> > stability-wise.
> [snip]
>> > In fact the last major thing I remember hearing about gcache is how to
>> > disable it ;)
>>
>> The gcache stuff worked fine for me in Apache-SSL 1.22 and mod_ssl
>> 2.0.3-1.3.1, at least under FreeBSD 2.2.6 and SSLeay 0.9.0b.
>>
>> (Perhaps Off-Topic:) But it's true that the gcache stuff is a little bit
>> annoying, especially because another process is running which means more
>> internal fiddling with child processes. That's why I currently thinking about
>> replacing the complete gache stuff with a DBM file on disk for mod_ssl 2.1.x.
>> That's similar to what Stronghold does. It looks more reasonable to me than an
>> extra stand-alone process running parallel. Or are there any security reasons
>> why the session cache should not stay on disk? Even when there are security
>> reasons for disk-storage then similar ones also exist for the in-core-storage.
>> Because one can attach a debugger to the gcache process to rip information the
>> same way one can lookup keys in a DBM file (ok, DBM is easier, but the
>> principle is the same). Opinions?
> IMHO I suggest that users need to know these things:
> 1. How much faster things are with gcache enabled.
> 2. How stable Apache-SSL is with gcache enabled compared to gcache
> disabled
> 3. Security issues when gcache is enabled
> Then we can individually decide if gcache is worth using.
I hope I answer the things correctly (Ben, please complain when you're
returned from vacation):
1. The gcache stuff is not really a "session cache". Actually
it's more a "session cache distribution mechanism". Because session ids are
cached by SSLeay per default. But because Apache 1.3 uses pre-forked server
processes, each of them uses their own SSLeay cache. So, as long as the
browser would each time only connect to the same process (not really
possible) the gcache stuff would be not needed. Because SSLeay already
caches in memory. But the problem is now that each server process has it's
own cache. Instead it is more reasonable that Apache as a whole uses a
single cache. That's not possible because of the pre-forking (separate
memory pools). The only way to emulate a global cache is to syncronize the
individual caches of the server processes. And that's for what gcache is
used. It _distributes_ the cache information between the processes.
2. The performance gain depends on the request balancing between
the servers processes. For instance when you use HTTP keep-alives and one
server handles more requests in squence the gcache provides nothing. But
when the clients establishes parallel connections (Netscape does 4 per
default) then usually different server processes serve the request. And
here the gcache stuff provides a performance gain. How much it is actually
in practice I don't know, too. But it's useful to use this cache
distribution mechanism. At least it's not a drawback ;-)
(BTW, Currently I'm thinking about replacing Apache-SSL's gcache approach (an
extra process running in parallel) by a simple disk-based hashfile solution
(DBM) or alternatively (not portable, so it's only an option) by a shared
memory based solution for mod_ssl 2.1.0. So, I'm still seeking for feedback on
this replacement idea. When someone is interested and want to share opinions
or suggestions, feel free to contact me or let us discuss the point on the
mod_ssl mailing list (sw-mod-ssl@engelschall.com). Thanks.)
Greetings,
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com