I've been looking into Vapor's Websocket Kit and the underlying Swift NIO for sending and receiving websocket data for my project. I discovered a few places of performance tuning opportunity in my project, but my idea relies on getting to know the current amount of buffered data in the channel pipeline. I realized that in Swift NIO, buffer size is not directly exposed through a simple interface like the bufferedAmount in browser's Websocket API. I did some research and found ChannelOptions.writeBufferWaterMark and isWritable, which won't give the buffered amount directly, but allow me to control the buffering behavior to some extent. Before I dive deeper, I'd like to ask if there is a better way to check the amount of buffered data in the pipeline?
Can you clarify the question a little bit? Specifically, do you want to know the amount of buffered outbound data, and do you want to know it including any data that's in the ChannelHandlers (if there is any), or only the amount that is pending being sent to the socket?
Hi Cory, sorry I didn’t describe my question clearly enough. Specifically, I’d like to know the amount of outbound data buffered in the pipeline, like those have been queued using calls to write() but not yet transmitted to the network.
Ok, so this splits into two cases:
- How much is buffered in the
Channel - How much is buffered in any ChannelHandlers.
The former is an easier question to answer than the latter, so we can start there.
This is a good question to be able to ask. Right now NIO doesn't have an API to answer that question, but it could. We could add a new ChannelOption that allows you to ask how many bytes are buffered (NIOBufferedWritableBytesOption). You could then get that ChannelOption, and we could have NIO's channels return the value.
This doesn't exist, but it should be a workable patch for a 3p contributor to make.
The latter one is harder. Some ChannelHandlers do buffer outbound bytes, either temporarily or indefinitely. To answer the question for them, we'd need to add a protocol and then audit handlers and get them to conform to that protocol. This is also do-able, but it's a bit more ambitious, so if I were you I'd start with part 1.
Thank for the proposals! Part 1 sounds doable.
I wonder if there is a better channel for me to discuss a few finer-grained details? Or I can try starting the design and implementation and we can discuss when I submit the PR?
I think the latter approach is best. Feel free to file a github issue for discussion as well if you'd prefer.