SSLContext get created unconditionally which can cause serious performance issues

[kissgyorgy]

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:

[florimondmanca]

@kissgyorgy Hi. Passing by here so figured I'd answer what this made me think about.

Transports can't know in advanced if it's going to be used for HTTP-only requests, or they'll have to do HTTPS requests too, which is why HTTPX creates one anyway.

I assume the solution of passing an existing transport should work. The part I'm surprised about is this:

but httpx closes the transport after finishing the request

Could you share some of the code you're using that's causing this behavior? The only situations when clients would close transports is in their .close()/.aclose() methods, or when exiting context managed blocks (with Client(): ... or async with AsyncClient(): ...).