proxy_buffering

[Francis Daly]

On Thu, Mar 15, 2012 at 07:10:47AM -0400, nginxer wrote:

Hi there,

> But one last question to see if I got this right:

I don't think you have.

"buffering" and "caching" are two different things. "caching" is not
involved here at all.

> Imagine following scenario:
> 
> The proxy_buffers are empty.

A proxy_buffer is associated with a single proxy_pass connection. So
the buffers are empty at the start and end of the connection, and may
hold something in between.

> A client wants to visit let's say google.com. Our php script gets

If you're using php and php-fpm and not apache, you're probably not
using proxy_pass but fastcgi_pass. That means the actual directives you
will want to use will probably start with fastcgi_ rather than proxy_,
but the outline is the same.

> the content of google.com, sends it to the client

Upstream doesn't talk to the client.

Upstream talks to nginx, and nginx talks to the client.

> and nginx will also buffer the response from google.com in a
> proxy_buffer.
> 
> Is that right so far?

Perhaps it is easier to think of the full process as a chain of processes.

web browser talks to nginx, over a 1 MB/s link.
nginx talks to upstream server, over a 100 MB/s link.
upstream server returns 100 MB of content to nginx.
nginx returns 100 MB of content to web browser.

With proxy_buffering on, nginx can hold the whole 100 MB, so the
nginx-upstream connection can be closed after 1 s, and then nginx can
spend 100 s sending the content to the web browser.

With proxy_buffering off, nginx can only take the content from upstream at
the same rate that nginx can send it to the web browser.

The web browser doesn't care about the difference -- it still takes 100
s for it to get the whole content.

nginx doesn't care much about the difference -- it still takes 100 s to
feed the content to the browser, but it does have to hold the connection
to upstream open for an extra 99 s.

Upstream does care about the difference -- what could have taken it 1
s actually takes 100 s; and for the extra 99 s, that upstream server is
not serving any other requests.

Usually: the nginx-upstream link is faster than the browser-nginx link;
and upstream is more "heavyweight" than nginx; so it is prudent to let
upstream finish processing as quickly as possible.

Hence buffering.

> So the next time if a client wants to visit google.com nginx will take
> the response from a proxy_buffer without making a request to
> google.com.
> 
> Right?

No. That would be caching. The directives to configure that tend to have
the word "cache" in them.

> If I understood it right, proxy_buffering is caching?
> 
> The term "proxied server" confused me...

When you "proxy_pass", what you proxy_pass to is the proxied server.

If you are using fastcgi_pass, then the content at

http://www.nginx.org/en/docs/http/ngx_http_fastcgi_module.html

is probably more interesting to you.

There is no explicit "fastcgi_buffering" directive; it is effectively
always "on".

	f
-- 
Francis Daly        francis at daoine.org