websocket: fix write back-pressure#618
Merged
darrachequesne merged 1 commit intosocketio:masterfrom May 4, 2021
Merged
Conversation
00067b5 to
1b32011
Compare
Websocket transport is eagerly writing to underlaying websocket
without respecting back-pressure.
When an event is emitted to multiple clients, socket.io adapter
sends the same packet object to all socket clients.
These packet objects are shared for all clients inside room.
Once the packet is sent to transport,
transport prepares buffer with transport headers and packet data
and the sharing among clients is lost.
This change significantly reduces memory usage when
many packets are emitted to many clients in a burst.
This change causes that buffered data is sent to clients
more evenly packet by packet.
Contributor
Author
|
Thank you! |
5 tasks
darrachequesne
pushed a commit
that referenced
this pull request
Jun 13, 2024
With the `websocket` transport, the callbacks which indicate that the
packets are actually written were not properly called.
Example:
```js
socket.send("hello", () => {
// the message has been written to the underlying transport
});
```
The bug was caused by the `websocket` transport (and `webtransport` as
well) having its `supportsFraming` property set to `true`, despite
having been changed in [1] to emit a single `drain` event for each
batch of messages written to the transport like the `polling` transport
always did. Note that although [1] is partially reverted in [2], the
new `drain` event behavior is preserved as called out in that commit's
message.
The `supportsFraming` attribute was introduced in [3] (amended by [4])
as a way to distinguish transports that emit one `drain` per message
from those that emit one `drain` per batch. Since the delivery of
`send` callbacks depends on matching `drain` events with
`transport.send` calls, that distinction is vital to correct behavior.
However, now that all transports have converged to "one `drain` per
batch" behavior, this `supportsFraming` property can be retired (and
the code for calling callbacks simplified).
[1]: #618
[2]: a65a047
[3]: #130
[4]: #132
Related: #698
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Websocket transport is eagerly writing to underlaying websocket
without respecting back-pressure.
When an event is emitted to multiple clients, socket.io adapter
sends the same packet object to all socket clients.
These packet objects are shared for all clients inside room.
Once the packet is sent to transport,
transport prepares buffer with transport headers and packet data
and the sharing among clients is lost.
This change significantly reduces memory usage when
many packets are emitted to many clients in a burst.
This change causes that buffered data is sent to clients
more evenly packet by packet.
This change slightly (up to 10%) improved write throughput in the tests where
many packets are emitted to many clients in a burst.
The kind of change this PR does introduce
Current behaviour
Websocket transport does not respect back pressure from underlaying websocket
New behaviour
Websocket transport respects back pressure from underlaying websocket
Other information (e.g. related issues)