-
Notifications
You must be signed in to change notification settings - Fork 595
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
core: disable server-side HTTP pipelining by default #3321
Conversation
Test PASSed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't performance suffer because this would cause many more TCP (and perhaps TLS) handshakes in scenario's where there's a lot of small requests (and perhaps head-of-line blocking isn't such an issue)? Or am I thinking of a different 'pipelining' feature there?
It's not about persistence but about pipelining. Pipelining helps only with the latency of sending over requests because responses still need to be delivered in order. The only place where I see it used in "practice" is in benchmarks where sending over multiple requests in one go helps with avoiding system calls.
This scenario would probably benefit from pipelining but you will first have to find a client which supports it. After all we are just following the way that curl went: https://daniel.haxx.se/blog/2019/04/06/curl-says-bye-bye-to-pipelining/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK then ;)
It's somewhat of an obscure feature which doesn't seem to be tested well.