From 37c491dcc23d445521229dbe902f02833f2a0f4c Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Wed, 27 Apr 2011 13:13:24 -0700 Subject: examples/nginx.conf: clarify proxy_buffering for Rails 3.1 I've tested with nginx 1.0.0 and confirmed "proxy_buffering off;" can cause Unicorn to block on a slow client reading a large response. While there's a potential (client-visible) performance improvement with Rails 3.1 streaming responses, it can also hurt the server with slow clients. Rainbows! with (ThreadSpawn or ThreadPool) is probably the best way to do streaming responses efficiently from all angles (from a server, client and programmer time perspective). --- examples/nginx.conf | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/examples/nginx.conf b/examples/nginx.conf index 52ec245..9f245c8 100644 --- a/examples/nginx.conf +++ b/examples/nginx.conf @@ -125,10 +125,15 @@ http { proxy_redirect off; # set "proxy_buffering off" *only* for Rainbows! when doing - # Comet/long-poll stuff. It's also safe to set if you're - # using only serving fast clients with Unicorn + nginx. - # Otherwise you _want_ nginx to buffer responses to slow - # clients, really. + # Comet/long-poll/streaming. It's also safe to set if you're using + # only serving fast clients with Unicorn + nginx, but not slow + # clients. You normally want nginx to buffer responses to slow + # clients, even with Rails 3.1 streaming because otherwise a slow + # client can become a bottleneck of Unicorn. + # + # The Rack application may also set "X-Accel-Buffering (yes|no)" + # in the response headers do disable/enable buffering on a + # per-response basis. # proxy_buffering off; proxy_pass http://app_server; -- cgit v1.2.3-24-ge0c7