Disabling TCP_NODELAY (Nagle's algorithm)

[Matt Billenstein]

Anyone tried disabling this when using a gevent wsgi server? Some info
here:

http://stackoverflow.com/questions/1781766/paste-httpserver-and-slowdown-with-http-1-1-keep-alive-tested-with-httperf-and-a

I'm using pastegevent and I dug into the gevent wsgi server a bit, but
haven't gotten as actually trying setting TCP_NODELAY on the underlying
socket...

thx

m

--
Matt Billenstein
ma...@vazor.com
http://www.vazor.com/

[Nicholas Piël]

On Sep 21, 2010, at 12:11 AM, Matt Billenstein wrote:

> Anyone tried disabling this when using a gevent wsgi server? Some info
> here:
>
> http://stackoverflow.com/questions/1781766/paste-httpserver-and-slowdown-with-http-1-1-keep-alive-tested-with-httperf-and-a
>
> I'm using pastegevent and I dug into the gevent wsgi server a bit, but
> haven't gotten as actually trying setting TCP_NODELAY on the underlying
> socket...
>
> thx

I am not sure if I completely follow you here. But the stackoverflow page refers to a Paster server specific bug which can be circumvented by setting the TCP_NODELAY socket option. Gevent does not show this behavior so I don't really see how it is related.

Just setting TCP_NODELAY without completely understanding why can even hurt your performance as it might cost you in extra TCP header overhead. However, in the case of a WSGI server which buffers the output already I do think it is best to turn it on. But still, the gains, if any, would be small and not something comparable to what has been shown in the paster bug report.

Cheers,
Nicholas

[Matt Billenstein]

On Tue, Sep 21, 2010 at 08:34:16AM +0200, Nicholas Pi?l wrote:
> I am not sure if I completely follow you here. But the stackoverflow
> page refers to a Paster server specific bug which can be circumvented
> by setting the TCP_NODELAY socket option. Gevent does not show this
> behavior so I don't really see how it is related.

Nagle's algorithm is on by default and I don't see any calls to
setsockopt in gevent to turn it off.

> Just setting TCP_NODELAY without completely understanding why can even
> hurt your performance as it might cost you in extra TCP header
> overhead. However, in the case of a WSGI server which buffers the
> output already I do think it is best to turn it on. But still, the
> gains, if any, would be small and not something comparable to what has
> been shown in the paster bug report.

My app commonly sends very small responses -- it's a waste in that case
to delay sending the response since there won't be any chance for
combining packets anyway.

I haven't done enough testing to know this is an issue, but was curous
to see if anyone else had noticed it with gevent http/wsgi servers.