On Wed, Jul 14, 2010 at 10:33:43PM +0100, Dr Stephen Henson wrote:
> On 25/06/2010 08:10, Paul Querna wrote:
> > I was playing with OCSP Stapling in 2.3.6-alpha tonight, and I noticed
> > that in the common case path, we will always lock a global mutex.
> >
> > I don't see why this is needed for the cache hit case that uses
> > non-SHM cache providers.
> >
> > In fact, modssl_dispatch_ocsp_request, which is called on a cache
> > miss, already has a serialize_request, so I'm not sure why there is a
> > global mutex at all, even for cache updates.
> >
> > It seems that inside stapling_mutex_{on,off} in ssl_util_stapling.c,
> > the global mutex should only be used if (mc->stapling_cache->flags &
> > AP_SOCACHE_FLAG_NOTMPSAFE) is true?
>
> The reason for this is to keep the number of OCSP queries to a minimum, which
> is
> the main purpose of stapling.
>
> If the cached response is acceptable the mutex will lock, retrieve and unlock
> which should be handled relatively quickly.
There are two independent uses of this lock though - serializing access
to the cache, and serializing access to the responder. The latter is
only required in the case of a cache miss or a cache hit with a stale
response. The former is required iff the socache backend has the
_NOTMPSAFE flag as Paul says.
So Paul's right that it's possible to optimize for a cache hit with a
valid response if using a lockless cache such that no locking is
required. (looks like it would require only minor rejigging of the
code)
Regards, Joe
