httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: ocsp stapling global mutex
Date Thu, 15 Jul 2010 15:40:00 GMT
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

Mime
View raw message