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

Decrease latency for small messages? #38

Closed
erikedin opened this issue Feb 25, 2018 · 1 comment
Closed

Decrease latency for small messages? #38

erikedin opened this issue Feb 25, 2018 · 1 comment
Assignees
Milestone

Comments

@erikedin
Copy link
Contributor

When creating a test which sent lots of messages of different sizes between my client and a Go server, I discovered that the latency for small messages is relatively high. The latency for larger messages is very low.
Some detective work indicates that when the message size is 1448 bytes (including frame overhead, so a payload of 1440), then the latency is high. A message size of 1449 and larger leads to low latency.

Apparently, 1448 bytes is some type of max size for a TCP message. A friend indicated that one might attempt to set the TCP option TCP_NODELAY, which is an option to not buffer as much, or something.

This does not appear to be a bug in my client, per se, but given that WebSocket message may well be small in size, there should be an option to fix this, if possible.

@erikedin erikedin added this to the Release 0.1.2 milestone Feb 25, 2018
@erikedin erikedin self-assigned this Feb 25, 2018
@erikedin
Copy link
Contributor Author

From the Distributed package in Base, the magic call to reduce latency for small messages is:
ccall(:uv_tcp_nodelay, Cint, (Ptr{Void}, Cint), sock.handle, 1).

This needs to be an option during the connection, since I have no idea what the effects would be for all users.

erikedin added a commit that referenced this issue Mar 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant