Re: HTTP streaming and Unicorn timeout

[Eric Wong]

Nokan Emiro uzleep...@gmail.com wrote:
 Hi guys,
 
 I am working on a Rails app that needs to stream some data to the user and
 I have just found out that Unicorn's timeout feature doesn't respect 
 streaming.
 Content generation is interrupted by Unicorn after the timeout is over.  I
 had to comment out the timeout line in the Unicorn config and use
 Rack::Timeout instead.  This way the streaming isn't interrupted, but the 
 normal
 requests (I mean those that don't use streaming) are forced to finish in the
 defined period of time.
 
 I'd like to know your opinion about that.  Why is Unicorn cutting off the app
 even if it streams actively to the user?  Is there any better solutions to my
 problem than using Rack::Timeout and switch off timing out in Unicorn?

unicorn isn't appropriate for long-running responses (taking up an
entire process is expensive), it is designed for fast responses to a
fast client able to read it quickly.

Using Rack::Timeout with Rainbows! instead of unicorn is probably a
better idea.

 Is that a bad idea that the timeout counter should restart counting after
 each byte/packet/chunk traverses trough the connection?

That'd be more expensive for the common case of fast responses
(which is what unicorn is designed for)
___
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

Re: A barrage of unexplained timeouts

[Eric Wong]

Jimmy Soho jimmy.s...@gmail.com wrote:
 fwiw, we experience this too irregularly, about once a week or 2 weeks
 for a few seconds, and sometimes up to a minute or 2 minutes long. for
 no apparent reasons indeed. and at random times.

Wait, based on what you say below, is this happening to unicorn or
nginx?

 my suspicion so far has always been that this is due to bad (wifi)
 networks of clients. what happens when a request is handled
 successfully by rails, but for whatever reason the last bit of the
 response can't be delivered because the receiving end is not consuming
 in a timely fashion?

So nginx is complaining about disconnected clients, not unicorn,
correct?

 If i'm not mistaken i think that rails logs a 200 success message
 before the response is actually send back?

Correct, rails/unicorn won't know if the client disconnected until
nginx breaks the connection to unicorn.

 Is a response send back by rails / unicorn fully buffered by nginx? Or
 is a unicorn worker blocked until the response is confirmed to have
 been successfully received by the client?

nginx fully buffers both requests and responses by default.
Which leads us to...

 Aside: how do you protect your unicorn workers against a barrage of
 client requests that eat the response veery slwly?

That's the whole point of using nginx with unicorn.  nginx shields
unicorn from slow clients.
___
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