Unicorn and streaming in Rails 3.1

[Xavier Noria <fxn@hashref.com>]

Streaming works with Unicorn + Apache. Both with and without deflating.

My understanding is that Unicorn + Apache is not a good combination
though because Apache does not buffer, and thus Unicorn has no fast
client in front. (I don't know which is the ultimate technical reason
Unicorn puts such an emphasis on fast clients, but will do some
research about it.)

I have seen in

    http://unicorn.bogomips.org/examples/nginx.conf

the comment

    "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."

If I understand how this works correctly, nginx buffers the entire
response from Unicorn. First filling what's configured in
proxy_buffer_size and proxy_buffers, and then going to disk if needed
as a last resort. Thus, even if the application streams, I believe the
client will receive the chunked response, but only after it has been
generated by the application and fully buffered by nginx. Which
defeats the purpose of streaming in the use case we have in mind in
Rails 3.1, which is to serve HEAD as soon as possible.

Is that comment in the example configuration file actually saying that
Unicorn with nginx buffering is not broken? I mean, that if your
application has some actions with stream enabled and you put it behind
this setup, the content will be delivered albeit not streamed?

If that is correct. Is it reasonable to send to nginx the header
X-Accel-Buffering to disable buffering only for streamed responses? Or
is it a very bad idea? If it is a real bad idea, is the recommendation
to Unicorn users that they should just ignore this new feature?
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying