[PATCH] Proxy: support configuration of socket buffer sizes
mdounin at mdounin.ru
Fri May 19 18:21:11 UTC 2017
On Thu, May 18, 2017 at 06:22:41PM +0000, Karstens, Nate wrote:
> I just wanted to follow up on this patch and make sure that the
> fraud detection notice or confidentiality notice added by my
> company wasn't precluding it from consideration.
No, it wasn't. And the fraud detection notice seems to be added on
your incoming mail, the mailing list copy don't contain anything
like this, see
Avoiding confidentiality noticies on public mailing lists might be
a good idea though.
> # HG changeset patch
> # User Nate Karstens <nate.karstens at garmin.com> # Date
> 1493467011 18000
> # Sat Apr 29 06:56:51 2017 -0500
> # Node ID 1251a543804b17941b2c96b84bd1f4e58a37bc15
> # Parent 8801ff7d58e1650c9d1abb50e09f5979e4f9ffbf
> Proxy: support configuration of socket buffer sizes
> Allows the size of the buffers used by the TCP sockets for HTTP
> proxy connections to be configured. The new configuration
> directives are:
> * proxy_socket_rcvbuf
> * proxy_socket_sndbuf
> These correspond with the SO_RCVBUF and SO_SNDBUF socket
> options, respectively.
> This is be useful in cases where the proxy processes received
> data slowly. Data was being buffered in three separate TCP
> buffers (nginx-from-client receive, nginx- to-proxy send, and
> proxy-from-nginx receive). The cumulative effect is that the
> client thinks it has sent all of the data, but times out waiting
> for a reply from the proxy, which cannot reply because it is
> still processing the data in its buffers.
In practice, we've never seen cases when default socket buffer
sizes on backend connections are not appopriate, and/or tuning
system default is not sufficient. So even, as you can see from
the code, nginx is able to tune SO_RCVBUF in
ngx_event_connect_peer(), this was never exposed to configuration.
This may be related to the fact that HTTP in general doesn't
really depends on particular parts of a request being buffered,
and nginx does not use pipelining in requests.
Could you please elaborate more on the use case where you see the
problem described, and why tuning system defaults is not
sufficient in your case?
More information about the nginx-devel