>> I'm re-submitting a patch to libcurl that reuses SSL_CTX objects across
>> multi objects (see http://curl.haxx.se/mail/lib-2007-03/0061.html). I
have
>> been using the code for a couple of months now without any sign of
problems.
>> The implementation (which is now simpler than the original patch) assumes
>> that the following openssl parameters are the same for all the multi
handles
>> 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
to
> 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
noticeable.

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
sense?
> Can't you just store those properties when you store the CTX in the cache
and
> verify that they are the same when you re-use it? Optionally, you could
re-use
> 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
instance
>> and are freed only when the share is.
>
> If we're adding this, I would rather like to see the multi handle
introduce
> automatic caching/sharing of CTX objects between the easy handles added to
it.
> 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
handles.

> 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.

Cheers,
Shmul
Received on 2007-08-21