Issue Details
Our application ends up with high counts of long-lived websockets that are mostly idle. I believe this is a common case for websocket-based applications in general.
Copying between the client and the backend for websockets today uses io.Copy. io.Copy always allocates a 32KiB buffer for the lifetime of the copy operation.
For our application, this wasted 64K per websocket connection is prohibitive. If we could tune it down it would significantly decrease our memory footprint with no real performance penalty (in our case).
I'm happy to open a PR if you're willing to accept a change like this. I think there are a few potential approaches. I think the simplest thing is to just keep the same behavior but pass in a new buffer of configurable size for every connection. I've implemented this on a branch. We could also try to make the non-websocket response buffering similarly configurable, but that's a bigger change because those buffers are pooled, and I'm skeptical it's as useful because request/responses are usually shorter lived. Happy to take a crack at implementing it any way you see fit.
Assistance Disclosure
AI not used
If AI was used, describe the extent to which it was used.
No response
Issue Details
Our application ends up with high counts of long-lived websockets that are mostly idle. I believe this is a common case for websocket-based applications in general.
Copying between the client and the backend for websockets today uses
io.Copy.io.Copyalways allocates a 32KiB buffer for the lifetime of the copy operation.For our application, this wasted 64K per websocket connection is prohibitive. If we could tune it down it would significantly decrease our memory footprint with no real performance penalty (in our case).
I'm happy to open a PR if you're willing to accept a change like this. I think there are a few potential approaches. I think the simplest thing is to just keep the same behavior but pass in a new buffer of configurable size for every connection. I've implemented this on a branch. We could also try to make the non-websocket response buffering similarly configurable, but that's a bigger change because those buffers are pooled, and I'm skeptical it's as useful because request/responses are usually shorter lived. Happy to take a crack at implementing it any way you see fit.
Assistance Disclosure
AI not used
If AI was used, describe the extent to which it was used.
No response