cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] SSL_CTX caching - revisited

From: Shmulik Regev <>
Date: Tue, 21 Aug 2007 15:36:27 +0300

>> I'm re-submitting a patch to libcurl that reuses SSL_CTX objects across
>> multi objects (see I
>> been using the code for a couple of months now without any sign of
>> The implementation (which is now simpler than the original patch) assumes
>> that the following openssl parameters are the same for all the multi
>> that are binded to a share instance that implements SSL_CTX reuse: cert,
>> cipher_list, CAfile, CApath.
> Did you do any measurements as to what impact or improvements this brings
> your app?

Yes. On my machine (WinXP, 2 GB RAM, Dual core 2.8 GHz) it shaves off around
150 ms. per instantiation of an SSL_CTX and the call to
SSL_CTX_load_verify_locations (which is really the time consuming part).

Normally I wouldn't bother with such optimizations but in my application it
made a noticeable difference. Why? My application acts similarly to a
forward proxy where libcurl is used for outgoing HTTP/S requests. The usage
pattern is to allocate a multi handle per domain and then share all the
concurrent requests made from the user's browser to the same domain are
using the same multi handle. This implies that new SSL_CTX objects were
allocated at least one per multi handle (possibly more depending on the
number of concurrent connections) which led us to optimize this process as
on slower machines a couple of hundreds of millies in page upload time are

Your mileage may vary of course - especially if a limited number of SSL_CTX
objects are allocated. This heavily depends on the usage pattern.

> Does this assumption about properties remaining the same really make
> Can't you just store those properties when you store the CTX in the cache
> verify that they are the same when you re-use it? Optionally, you could
> the CTX no matter what and set these properties (if they differ from the
> previous time).

I think that under most usage patterns the location of the trusted
certificates file/directory is the same as well as the client certificate.
Do you have a different view of it? Once we agree on the set of possibly
varying "keys" to the cache (currently only the method is), I can easily
change the caching strategy.

>> The SSL_CTX objects (one per SSL_METHOD) are managed by the share
>> and are freed only when the share is.
> If we're adding this, I would rather like to see the multi handle
> automatic caching/sharing of CTX objects between the easy handles added to
> In a similar manner to how it does for other caches.
I'm not sure I fully understand your intent, but are you suggesting we move
it out of the share and into the multi? If so, I think my mentioned usage
pattern would not have benefited from such an association. Share seems like
a natural place to cache data that can be reused across multi and easy

> Some nits in the code:

Thanks for letting me know. I fixed it (though I'll send the patch once we
agree on its contents). It is worth noting that MSVC doesn't warn about
uninitialized variables when running with warning level 3, nor does it warn
about unused parameters (it does on unused variables). Warning level 4 is
better but it warns about a couple of other issues (like initial_tv not
being initialized in select.c and other stuff). If you want I can work on
solving these warnings.

Received on 2007-08-21