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

Disable Nagle's #2134

Closed
mwethington opened this issue Nov 15, 2016 · 7 comments
Closed

Disable Nagle's #2134

mwethington opened this issue Nov 15, 2016 · 7 comments
Labels

Comments

@mwethington
Copy link

@mwethington mwethington commented Nov 15, 2016

Can we consider disabling Nagle's

This flag (TCP_NODELAY) is an option that can be enabled on a per-socket basis and is applied when you create a TCP socket. This is done for a purpose: Nagle's algorithm is generally useful and helps handle network congestion. I doubt you want to disable it system-wide since your system will probably suffer from this deactivation.

To disable it for a given socket, you can apply the option TCP_NODELAY as explained here and here in C:

int flag = 1;
int result = setsockopt(sock, /* socket affected /
IPPROTO_TCP, /
set option at TCP level /
TCP_NODELAY, /
name of option */
(char ) &flag, / the cast is historical cruft /
sizeof(int)); /
length of option value */
if (result < 0)
... handle the error ...

@tfheen
Copy link
Contributor

@tfheen tfheen commented Nov 15, 2016

]] Bill Bell

Can we consider disabling Nagle's

This was done in 3.0.4 rc1 already, or are you seeing cases where it's
still on?

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

@mwethington
Copy link
Author

@mwethington mwethington commented Nov 15, 2016

Not seeing it on the server calls. I do see it on the accept

Bill Bell
Sent from mobile

On Nov 14, 2016, at 10:35 PM, Tollef Fog Heen <notifications@github.commailto:notifications@github.com> wrote:

]] Bill Bell

Can we consider disabling Nagle's

This was done in 3.0.4 rc1 already, or are you seeing cases where it's
still on?

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/2134#issuecomment-260551943, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA4V-pzwmSqHZ-8A9bAMntX0MqwOkREQks5q-USQgaJpZM4KyFoD.

@tfheen
Copy link
Contributor

@tfheen tfheen commented Nov 15, 2016

]] Bill Bell

Not seeing it on the server calls. I do see it on the accept

Right, we might not be setting it on outbound connections to backends.
That should probably be checked. I thought we did, but I could be
wrong.

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

fgsch added a commit to fgsch/varnish-cache that referenced this issue Nov 19, 2016
fgsch added a commit to fgsch/varnish-cache that referenced this issue Nov 20, 2016
@bsdphk
Copy link
Contributor

@bsdphk bsdphk commented Nov 21, 2016

This is such a fundamental change in networking behaviour that I want to see some emperical data why this is a good idea, and preferably also when it is not (distant backend ?)

I havn't had time to digest this, but it may be relevant: https://tools.ietf.org/html/draft-stenberg-httpbis-tcp-00

@fgsch
Copy link
Member

@fgsch fgsch commented Nov 21, 2016

The part specific to Nagle's algorithm:

4.3.  Nagle's Algorithm

   Nagle's Algorithm [RFC0896] is the mechanism that makes the TCP stack
   hold (small) outgoing packets for a short period of time so that it
   can potentially merge that packet with the next outgoing one.  It is
   optimized for throughput at the expense of latency.

   HTTP/2 in particular requires that the client can send a packet back
   fast even during transfers that are perceived as single direction
   transfers.  Even small delays in those sends can cause a significant
   performance loss.

   HTTP/1.1 is also affected, especially when sending off a full request
   in a single write() system call.

   In POSIX systems you switch it off like this:

   int one = 1;
   setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(one));

@bsdphk
Copy link
Contributor

@bsdphk bsdphk commented Dec 5, 2016

OK

@bsdphk bsdphk added the a=OK'ed label Dec 5, 2016
@fgsch fgsch closed this in 0205cdf Dec 5, 2016
hermunn added a commit that referenced this issue Dec 8, 2016
@hermunn
Copy link
Member

@hermunn hermunn commented Dec 8, 2016

Backport review: The patch in master, 0205cdf, was just backported as 72435ed.

wmfgerrit pushed a commit to wikimedia/operations-debs-varnish4 that referenced this issue Feb 20, 2017
This release disables Nagle's algorithm on backend connections:
varnishcache/varnish-cache#2134

Full changelog here:
https://github.com/varnishcache/varnish-cache/blob/4.1/doc/changes.rst#varnish-cache-415-2017-02-09

Change-Id: I95f33c787a246265bc8841fd64c1fa3e2ed4e4a3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants