-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
asyncio: set TCP_NODELAY flag by default #71643
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
Comments
tl;dr TCP_NODELAY should be set by default and/or there should be a I've ported ZEO, ZODB's client-server networking layer to asyncio. After some digging, I came across this: Then led me to try setting TCP_NODELAY, which provided Linux Issue 311 suggested that this was a kernal-version issue. I think I originally tried this on Ubuntu 14.04, with kernal Finally, I tried an Amazon standard AMI, which runs some version of Note that the non-slow kernal version was lower than the slow (Ubuntu) I couldn't find a way to set TCP_NODELAY cleanly. Did I miss something? I ended up having to set the option on _sock transport attributes, I think TCP_NODELAY should be set by default. Perhaps it shouldn't be I also think there should be a way to set it cleanly. IMO, this is extremely important. Linux is a wildly important platform |
Gaaa, forgot to set meta data. |
See also python/asyncio#286 I also wanted to raise this question. I think transports should set NODELAY by default (as Golang, for instance). I've been hit by this thing a few times already -- performance of protocols over TCP is terrible because somebody forgot to set this flag. |
I forgot to switch to the asyncio branch of ZEO when testing on the Amazon/RedHat linux. When I do, the tests run slow there too. Asyncio is dog slow on every linux I've tried. |
Fine with me -- I have no idea what this flag does (nor the desire to learn :-). |
Jim, I can make a PR, unless you want to do that. |
Yury, I'd be fine with you making a PR. :) Is there a similar update that can be made to uvloop? |
Yes. Once it's committed to asyncio, I'll add it to uvloop immediately. That's one benefit of using uvloop -- it gets updates faster ;) |
I missed the point that you can get a transport's socket using get_extra_info. IMO, this provides an adequate escape from the default and qualifies as a "proper way to set it". I still think the default should be to enable TCP_NODELAY. |
vote +10 for that |
New changeset 3f7e4ae9eba3 by Yury Selivanov in branch '3.5': New changeset 10384c5c18f5 by Yury Selivanov in branch 'default': |
Committed, should be in 3.6 b1. |
Seems like this fix is incomplete. It contains this check:
But sock.type is not only a type (at least in Linux and FreeBSD), it also may contain SOCK_NONBLOCK and SOCK_CLOEXEC flags. So I'm hitting the same problem: on the Linux in asyncio I have:
So this check isn't working and TCP_NODELAY still disabled by default. Links:
Linux has SOCK_TYPE_MASK definition equal to 0xf, but I can't find such definition in the FreeBSD sources. And I don't know how to reliably and with forward compatibility check sock.type without calling getsockopt() syscall. Currently I have a fix in my project, where: _sock_type_mask = 0xf if hasattr(socket, 'SOCK_NONBLOCK') else 0xffffffff And then in my own _set_nodelay(sock) function:
Should I make a pull request or someone knows more reliable check? Or it is ok to add one more syscall?
|
Good catch. I made a PR to fix this. |
Oh, right. I wrote PR 4233 to fix the code. Yury: "Good catch. I made a PR to fix this." Oops. If you wrote a PR, would it mind to compare it with mine, please? |
_ipaddr_info() also uses "type == socket.SOCK_STREAM". Is it ok? |
Yury: thanks for fixing socket.socket.type. asyncio code now looks simpler and easier to follow without the helper functions just to test the socket type for equality. |
Note, TCP_NODELAY can not be set on UNIX streaming socket. Do you have corresponding tests for UNIX sockets ? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: