diff options
author | Eric Wong <normalperson@yhbt.net> | 2011-04-27 13:13:24 -0700 |
---|---|---|
committer | Eric Wong <normalperson@yhbt.net> | 2011-04-27 13:30:47 -0700 |
commit | 37c491dcc23d445521229dbe902f02833f2a0f4c (patch) | |
tree | 86de7b439645463878eb7f506ec3e15badd7f644 | |
parent | 1b3befbadb99c83c24109f68b719276f0051c7fb (diff) | |
download | unicorn-37c491dcc23d445521229dbe902f02833f2a0f4c.tar.gz |
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).
-rw-r--r-- | examples/nginx.conf | 13 |
1 files 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; |