Reduce memory usage by SSLStream

[davidfowl]

Description

For long running scenarios where reads are pending and data is only occasionally sent back and forth, the cost of using SSLStream is high from a memory POV. Today SSL Stream allocates a 8K buffer for the handshake and a 32K buffer per read. It optimizes for reading the TLS header and payload into the same buffer and in the end copies that to the user specified buffer.

Regression?

No

Data

A demo of 5000 websocket connections connected to an ASP.NET Core server using Kestrel:

Here's a heap dump sorted by inclusive size. Most of what is being held onto is array pool buffers.

Allocation profile of 5000 websocket connections. You can see the array pool has the most byte[] allocations.

They're mostly in the handshake and reading (I'm not writing in this app), just sitting mostly idle with ping pongs:

Analysis

We support specifying the buffer size for SslStream, much like FileStream, so that the user provided buffer can be used instead of the internal buffer to reduce memory usage. A bufferSize of 1 would signal to the SslStream that the buffer shouldn't be used.

I don't think we need a handshake buffer size...

The problem is SslStream has 5 constructors...

public class SslStream
{
+ public SslStream(Stream innerStream, bool leaveInnerStreamOpen, RemoteCertificateValidationCallback userCertificateValidationCallback, LocalCertificateSelectionCallback? userCertificateSelectionCallback, EncryptionPolicy encryptionPolicy, int bufferSize)
}

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

For long running scenarios where reads are pending and data is only occasionally sent back and forth, the cost of using SSLStream is high from a memory POV. Today SSL Stream allocates a 8K buffer for the handshake and a 32K buffer per read. It optimizes for reading the TLS header and payload into the same buffer and in the end copies that to the user specified buffer.

Regression?

No

Data

A demo of 5000 websocket connections connected to an ASP.NET Core server using Kestrel:

Here's a heap dump sorted by inclusive size. Most of what is being held onto is array pool buffers.

Allocation profile of 5000 websocket connections. You can see the array pool has the most byte[] allocations.

They're mostly in the handshake and reading (I'm not writing in this app), just sitting mostly idle with ping pongs:

Analysis

We support specifying the buffer size for SslStream, much like FileStream, so that the user provided buffer can be used instead of the internal buffer to reduce memory usage. A bufferSize of 1 would signal to the SslStream that the buffer shouldn't be used.

The problem is SslStream has 5 constructors...

public class SslStream
{
+ public SslStream(Stream innerStream, bool leaveInnerStreamOpen, RemoteCertificateValidationCallback userCertificateValidationCallback, LocalCertificateSelectionCallback? userCertificateSelectionCallback, EncryptionPolicy encryptionPolicy, int bufferSize):  base(innerStream, leaveInnerStreamOpen)
}

Author:	davidfowl
Assignees:	-
Labels:	area-System.Net.Security, tenet-performance, untriaged
Milestone:	-

[geoffkizer]

We need the entire frame buffered in order to decrypt it. So we can't allow the user to dictate the buffer size.

[geoffkizer]

I do wish we used the same buffer for the handshake and the app data.

[davidfowl]

We need the entire frame buffered in order to decrypt it. So we can't allow the user to dictate the buffer size.

I don't understand this. Can you elaborate? Is it because the user has to pass a minimum size buffer in to decrypt the frame?

[wfurt]

BTW the handshake buffer should be returned back when handshake finishes. So it may not really matter. We could unify them but the renegotiation path would need to done carefully. e.g. handshake starts again during read/write

[wfurt]

It feels like this could be driven by buffer size passed to Read, right? If somebody passes buffer size of 1, we probably d not need huge buffer. While somebody can pass in large chunk it suggest that build read (e.g. multiple frames make make sense). This would have benefit that it can be related to HTTP data e.g. be more flexible based on content rather than set once in constructor.

The note about the frames: I'm not sure if we can always decrypt less than one TLS Frame. While the API (schannel/OpensSSL) is not about frames, the buffering may happen internally. We may not see managed buffers but the memory may be taken anyway.
The old code would red 5byte header to know length of incoming frame before allocating the buffer. But that makes it quite inefficient.

Also note that the buffers are transient and rented from pool. That are not necessarily linked to life cycle of the stream.

[davidfowl]

It feels like this could be driven by buffer size passed to Read, right? If somebody passes buffer size of 1, we probably d not need huge buffer.

That's right, if the buffer is passed to ReadAsync is

It feels like this could be driven by buffer size passed to Read, right? If somebody passes buffer size of 1, we probably d not need huge buffer.

That sounds reasonable. It's really about controller the memory usage of the internal buffer. FileStream has a similar optimization so I took from prior art. If you feel like we could mostly avoid the buffer completely in SSLStream without that, then I'll defer to you.

The old code would red 5byte header to know length of incoming frame before allocating the buffer. But that makes it quite inefficient.

It's much better from a memory POV which is why you should let the caller control it so that they can optimize for the scenario they care about. In ASP.NET Core, the Stream that SSLStream wraps doesn't make sys calls, it's buffered so that cost is low compared to if you were wrapping a NetworkStream and making sys calls per read.

Also note that the buffers are transient and rented from pool. That are not necessarily linked to life cycle of the stream.

Take a look at the memory profile above. These reads are long running and the buffers will remain rented from the pool for as long as these reads are pending, which is a long time. The memory allocated today in a typical websocket scenario on the server side is 32K (SSLStream) + 4K (Kestrel's buffer) * number of websocket connections.

We're extremely memory efficient without TLS for a number of reasons, but here's a working set comparison for the same workload:

5000 websocket connections without TLS - 200MB
5000 websoket connections with TLS - 800MB

This also exacerbates the fact that the Kestrel memory pool doesn't currently shrink (our problem not yours). But this is less of an issue with non-TLS because we basically only use the memory pool once IO is ready.

[wfurt]

I will take a look @davidfowl. I'm remote this week and off-grid next week. But I think we should be able to look into this in 6.0.

[geoffkizer]

We need the entire frame buffered in order to decrypt it. So we can't allow the user to dictate the buffer size.

I don't understand this. Can you elaborate? Is it because the user has to pass a minimum size buffer in to decrypt the frame?

We have to pass the entire frame to SCHANNEL. Otherwise it can't decrypt the frame, and will give us an error like SEC_E_INCOMPLETE_MESSAGE.

[davidfowl]

We have to pass the entire frame to SCHANNEL. Otherwise it can't decrypt the frame, and will give us an error like SEC_E_INCOMPLETE_MESSAGE.

I see, so we can read the frame header to get the length and determine if we can full fill the request using the user's buffer or decide if we need to need an internal buffer to complete the operation successfully.