On Fri, 1 Jul 2016, Ray Satiro via curl-library wrote:
It seems possible you could actually hurt performance in some cases and end up doing the opposite of what you intended.
Yes that's true, but the question for me is how often it is likely to be good vs bad. How much of or protocols these days are lots of smaller pieces send back and forth and how we handle that internally already.
Clearly TLS handshakes improve significantly with this option set. That's a significant amount of all transfers. HTTP is more or less unchanged, unless for repeated HTTP requests where setting this option helps. The pingpong protocols where we send lots of tiny commands and wait for a response, should improve. SFTP should also benefit from it for the same reason.
Maybe there are some specific scenarios where all users could get provably better performance using NODELAY but using it for everything seems too far. Can you make a better case for this? I haven't seen enough to back this up so for now I vote -1.
Well, you could also turn that around. Previously we had it _disabled_ for everything (except HTTP/2) when clearly a huge amount of protocols would benefit from having it enabled.
We could of course make the enabling a more fine grained thing. Which protocols would you suggest we should not have it enabled for? I can't think of any obvious candidates since we're buffering internally anyway for most of the cases that I can immedaitely think could hurt from this (like Dan's mentioned case if we had been sending request headers one by one or similar).
I just think it helps more than it hurts so switching the default seems reasonable.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
