Welcome! Log In Create A New Profile


Re: proxy_buffering

Francis Daly
March 15, 2012 06:08PM
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


is probably more interesting to you.

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

Francis Daly francis@daoine.org

nginx mailing list
Subject Author Posted


nginxer March 14, 2012 05:18PM

Re: proxy_buffering

Alexandr Gomoliako March 14, 2012 05:42PM

Re: proxy_buffering

geberhart March 14, 2012 06:44PM

Re: proxy_buffering

nginxer March 14, 2012 06:57PM

Re: proxy_buffering

Alexandr Gomoliako March 14, 2012 08:10PM

Re: proxy_buffering

nginxer March 15, 2012 07:10AM

Re: proxy_buffering

Francis Daly March 15, 2012 06:08PM

Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 63
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready