Skip to content
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

Vectorized send #325

Open
AmineDiro opened this issue Mar 30, 2024 · 2 comments
Open

Vectorized send #325

AmineDiro opened this issue Mar 30, 2024 · 2 comments

Comments

@AmineDiro
Copy link

AmineDiro commented Mar 30, 2024

Hello,

Thanks a lot for the work you've done in this crate!

I currently use tokio-tungstenite to write a high-performance client for benchmarking multiple Websocket libraries. The client-side code connects ~10_000 ws connections to the server and writes a batch of messages. When profiling the client code, I found the repeated call to __libc_sendto syscall which adds a lot of overhead given the test setup. For performance reasons, I wanted to write the batch of messages using a single writev syscall.

Looking at the code I found that the WebsocketStream implements Sink for an underlying Stream : AsyncRead + AsyncWrite

impl<T> Sink<Message> for WebSocketStream<T>
where
    T: AsyncRead + AsyncWrite + Unpin,

Is there an easy way to access the inner stream to call write_vectored ? Thanks for your help

@daniel-abramov
Copy link
Member

Hi,

thanks for showing interest in benchmarking tokio-tungstenite Note that denoland/fastwebsockets have implemented an interesting benchmark and have already tested tokio-tungstenite.

As for your question - you are touching on a topic that is a known problem in tokio-tungstenite. Unfortunately, we can't add such support easily due to a major constrain of our underlying library tungstenite operating on Read + Write streams, in other words, the actual reading/writing happens inside tungstenite and we have a kludge in tokio-tungstenite to implement Read + Write for AsyncRead + AsyncWrite types that don't implement Read + Write (the requirement from tungstenite).

I've summarized most of the information related to performance here: snapview/tungstenite-rs#352 (comment). We have not addressed these issues yet as no one of the current maintainers actively uses the library, so it has stalled a bit.

@AmineDiro
Copy link
Author

Hi, thanks for the very detailed response! I'll take a look at the links 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants