-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory consumption by Idle HTTPS/TLS Connections #4721
Comments
We should look at adding a benchmark here added to our performance infrastructure. |
Remember that there is overhead inside SChannel / OpenSsl per connection as well (that is in process as well so will increase commit bytes). Are you measuring this on windows or Linux currently? There are some settings for Openssl that can be used to alleviate some memory pressure by allowing buffers to be shared/reclaimed from idle connections that I have mentioned previously in other conversations |
I am happy to help with this if you want someone to help out. |
We'll revisit this after @jkotalik's pipe changes are in. We don't think there's anything to do in Kestrel after that. Any other optimization would have to come from CoreFX. |
@Tratcher did you try anything here? |
No, this is not on my radar. |
I've done a bunch of work here. I'll put it in preview4 because there's some pending work in the BCL (dotnet/runtime#49573) |
[Reposting from an e-mail thread]
When I was doing IoT for example, we measured that an idle HTTPS/TLS connection can suck as much as 128 KB of memory. For Gateway scenarios, where connections can be mostly idle, but they need to be there this is very expensive. If I remember correctly the problem was SSL libraries requiring a couple of 32KB or 64KB buffers no matter what.
Ideally, you want 'idle' connections to truly cost 0 Bytes of memory or very close to it.
And this is relatively simple to test, create a HTTPS server with 100,000 TLS connections doing nothing, take note of the Commit Bytes, divide by 100,000.
Do you know in .NET Core what is the cost?
A lot of that overhead is cached request structures and pipe buffers designed to make active connections faster. We could consider discarding some of those cached objects if the connection is idle for a certain period of time. What if we only held it via a weak reference when the connection was idle?
The text was updated successfully, but these errors were encountered: