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

Mixing sendfile, tcp_nodelay and tcp_nopush illogical? #5

Closed
rokcarl opened this issue Jul 4, 2019 · 2 comments
Closed

Mixing sendfile, tcp_nodelay and tcp_nopush illogical? #5

rokcarl opened this issue Jul 4, 2019 · 2 comments

Comments

@rokcarl
Copy link

rokcarl commented Jul 4, 2019

The following article suggests that mixing sendfile, tcp_nodelay and tcp_nopush makes no sense.

I'd love to hear your thoughts on this and can really many of the resources be wrong about it?

@saamalik
Copy link

saamalik commented Nov 6, 2019

Hi @rokcarl - I think it's advocating for all three flags simultaneously.

When set indicates to always queue non-full frames. Later the user clears this option and we transmit any pending partial frames in the queue. This is meant to be used alongside sendfile() to get properly filled frames when the user (for example) must write out headers with a write() call first and then use sendfile to send out the data parts. TCP_CORK can be set together with TCP_NODELAY and it is stronger than TCP_NODELAY.

@rokcarl
Copy link
Author

rokcarl commented Nov 8, 2019

I read the article differently.

Either way, I'm not convinced by the article, especially after reading Nginx High Performance . For my use-case as a reverse proxy, just setting tcp_nodelay worked fine and the other two switches yielded no improvements, as expected.

@rokcarl rokcarl closed this as completed Nov 8, 2019
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

2 participants