fix(ssl): add lru_cache for create_ssl_context

[shepilov-vladislav]

Summary

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[T-256]

Thanks for the PR, I like the solution. This is high memory usage I encountered when using tons of Client instance in an app (I need them for several reasons).

But perhaps you would like to see and wait for #3022

@karpetrosyan could new httpx.SSLContext cachable?

[karpetrosyan]

Are we really capable of doing something like this? What if the SSL context is modified? Why should any subsequent function call return the modified SSL context?

I mean...

importsslfromfunctoolsimportcache@cachedefget_ssl_context():
returnssl.create_default_context()
first_ssl=get_ssl_context()
first_ssl.check_hostname=Falsesecond_ssl=get_ssl_context()
print(f.check_hostname) # False

[shepilov-vladislav]

@T-256, @karpetrosyan First of all thank you for your quick response and help.

The thing is that we make a lot of requests using http and we tried to replace httpx with aiohttp and saw that CPU consumption decreased many times, after that I went to compare the code base and saw that aiohttp just caches the creation of SSLContext - see here.

After adding caching - CPU consumption dropped by more than 4x on our Pods. If there is another more correct way to do it - please advise. I haven't found a way to do it without changing the httpx codebase.

Perhaps this PR will provide that opportunity, but I'm not sure

If you still find my changes useful, just tell me, I'll fix the tests and we'll merge this one out ✌️

[karpetrosyan]

We should probably wait until #3022 is marged before we consider adding cache at that layer. I like this idea, because configuring SSL context is a very expensive job.

Ref: karpetrosyan/hishel#139

[lovelydinosaur]

After adding caching - CPU consumption dropped by more than 4x on our Pods.

Prob indicates that you're instantiating clients repeatedly, and losing out on the benefits of connection pooling.

We should probably wait until #3022 is marged before we consider adding cache at that layer.

Would be simpler to consider then yep. (Anyone want to open a "SSL Cache" discussion?)

[T-256]

Anyone want to open a "SSL Cache" discussion?

I don't think we would need that. by refer to this comment, it'd be do the same job of caching to use single global variable cross clients.
Also, for whose using default ssl contexts, As you said in here it's good to have DEFAULT_SSL_CONTEXT = httpx.SSLContext() that used by Client by default.