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

Sendfile support #19

Open
samcode206 opened this issue Jan 17, 2024 · 1 comment
Open

Sendfile support #19

samcode206 opened this issue Jan 17, 2024 · 1 comment

Comments

@samcode206
Copy link
Owner

samcode206 commented Jan 17, 2024

It wouldn't be too much trouble to expose a ws_conn_sendfile function that takes a file descriptor, size, and an opcode, write the header then call sendfile on the provided fd. can be useful for sending static data and we don't have to waste event loop time copying in userspace.

sendfile (2)

@samcode206
Copy link
Owner Author

sendfile is cool but copying maybe better for smaller files, especially for file content already in memory, in fact similar to writev I bet for smaller buffers it's faster to just memcpy then send. I have tested this in the past but don't have any numbers atm. won't hurt to include that as a fair warning in docs so no one goes crazy with sendfile thinking it's making things faster.. its ideally something people test for their own use case before jumping straight in because they heard it's faster or it's faster "in theory".

overall I think sendfile can be valueable if:

  • the file is not opened or read, in this case we open to get an fd then sendfile (2 syscalls) and not have to read it esp if we don't care about the content. we just let the kernel deal with it.
  • the file is large (can't put a number on large where sendfile is faster without testing)
  • many connections are being sent the same static file (again it may still be faster to just copy it each time depending on size)

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

No branches or pull requests

1 participant