SSLContext get created unconditionally which can cause serious performance issues

[kissgyorgy]

Discussed in #2245

^{Originally posted by kissgyorgy May 25, 2022}
Our use case is that we built an API Gateway, in which we use httpx as a client to connect to the backend service.

We have a multi-tenant system, so we make a new httpx client every time to isolate customer requests completely.
We have a serious performance issue this way, we measured it, and every request takes 100ms longer just because a ssl.SSLContext is created unconditionally, so we spend a lot of time building SSLContexts, which we don't need anyway, because we don't need an HTTPS connection to the backend, as the two services are on the same machines.

I tried to solve it by passing in a global httpx.AsyncHTTPTransport, but httpx closes the transport after finishing the request, and I was very confused by that so I didn't thought it could be solved this way.
The next thing I tried to implement a global connection pool, so the SSLContext would be created at application startup only once, but because of a serious bug in httpcore about corrupted connections, we couldn't do that either (we would have hit the same bug with the global transport implementation too).

A trivial implementation would be to only create ssl.SSLContext in case of HTTPS connections, which httpcore is already doing correctly, but for some reason, httpx does this unconditionally.

Another implementation idea by @vlaci that there could be an ssl_context_factory, which could be implemented by users.

Here is a py-spy snapshot analyzed with speedscope, which shows we spend half the time creating unused SSLContexts:

[tomchristie]

I think you'd find the same behaviour here with requests or urllib3.

I'd suggest either reusing the same transport as @florimondmanca suggested in #2245. You could also just share a single ssl context by creating a global SSL context instance that you pass in to each client with verify = ssl_context.

For now I'd suggest we close this off, as this isn't an issue when you:

• Share a single client.
• Share a single transport across multiple clients.
• Share a single ssl context across multiple clients.

I do think there's some possible scope for improvement here, both around the API for SSL configuration, and potentially also for reusing rather than recreating SSL contexts, but at this point in time I don't think we'd want to consider either of those as being in scope.