Proxy_buffering

Server NGINX
1

Hey Guys,

I’m new to nginx and have a question about the proxy_buffering feature.
Our topology is very easy:
Just nginx - No apache behind it.
Our site gets the content (text,pictures,videos) of different sites via
php and serves it to the client.

My question is:
Do we need the proxy_buffering? Could we turn it off without performance
issues?
I really don’t understand this feature, maybe someone could explain it
for me. :slight_smile:

Thanks!

Posted at Nginx Forum:

2

I’m new to nginx and have a question about the proxy_buffering feature.

Our topology is very easy:
Just nginx - No apache behind it.
Our site gets the content (text,pictures,videos) of different sites via
php and serves it to the client.

My question is:
Do we need the proxy_buffering? Could we turn it off without performance
issues?

You do need it. Otherwise any slow client will block an entire php
process for a long time.

I really don’t understand this feature, maybe someone could explain it
for me. :slight_smile:

http://mailman.nginx.org/pipermail/nginx/2012-March/032608.html

3

This does not help! :-/

One says that I need it and the other says I don’t.
Maybe the information I provided are too lean.

We run php-fpm and nginx on the same server.
The php scripts will get the contents from different sites and sends
them to the client.
We do NOT own these “different sites” (= Google, Flickr, Youtube)

@Alexandr G.:
I still don’t understand what proxy_buffering really does.
When a client wants to visit Google, the php script will get the content
from Google and sends it to the client.

So where is the role of proxy_buffering?
Could you provide a scenario how proxy_buffering will exactly work for
our topology?

Thanks!

Posted at Nginx Forum:

4

Enabling proxy_buffering, disk I/O will increase significantly. If
you’re
running nginx and php on the same server, maybe it’s not a good idea to
enable it.

5

On Thu, Mar 15, 2012 at 12:57 AM, nginxer [email protected] wrote:

This does not help! :-/

One says that I need it and the other says I don’t.
Maybe the information I provided are too lean.

It was fine.

Have you read this?
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering

I’m not sure what is so confusing about it. If you can receive an
entire response from your giant php process you can send another
request there right away, making it a lot more efficient, so it won’t
occupy those amounts of memory for nothing. Unless you have a lot of
memory.

6

OK.
The last link from you was helpful!

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

Imagine following scenario:

The proxy_buffers are empty. A client wants to visit let’s say
google.com. Our php script gets the content of google.com, sends it to
the client and nginx will also buffer the response from google.com in a
proxy_buffer.

Is that right so far?

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?

If I understood it right, proxy_buffering is caching?

The term “proxied server” confused me…

Thanks Alexandr G.!

Posted at Nginx Forum:

7

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 D. [email protected]