HTTP streaming and Unicorn timeout

HTTP streaming and Unicorn timeout

[Nokan Emiro]

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?

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

Thanks for any comments, suggestions and observations,
U.
_______________________________________________
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: HTTP streaming and Unicorn timeout

[Eric Wong]

Nokan Emiro <uzleepito@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: HTTP streaming and Unicorn timeout

[Nokan Emiro]

Thank you for your answer Eric.

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

99% of the requests are fast and can be served far below 300 ms.  Only
a few type of requests need to stream lots of data.  Do you really think that
unicorn isn't a good choice in this case and I should consider switching to
something else (Rack::Timeout + Rainbows!, Puma or whatever) just for the
sake of that 1%?

u.
_______________________________________________
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: HTTP streaming and Unicorn timeout

[Hongli Lai]

Maybe you can use a combination. Use Nginx location blocks to forward
most requests to Unicorn, and forward the streaming URLs to Passenger
Enterprise/Rainbows/Puma/etc.

On Thu, Aug 22, 2013 at 5:26 PM, Nokan Emiro <uzleepito@gmail.com> wrote:
> Thank you for your answer Eric.
>
>> Using Rack::Timeout with Rainbows! instead of unicorn is probably a
>> better idea.
>
> 99% of the requests are fast and can be served far below 300 ms.  Only
> a few type of requests need to stream lots of data.  Do you really think that
> unicorn isn't a good choice in this case and I should consider switching to
> something else (Rack::Timeout + Rainbows!, Puma or whatever) just for the
> sake of that 1%?
>
> u.
> _______________________________________________
> 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



-- 
Phusion | Ruby & Rails deployment, scaling and tuning solutions

Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)
_______________________________________________
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: HTTP streaming and Unicorn timeout

[Eric Wong]

Nokan Emiro <uzleepito@gmail.com> wrote:
> Thank you for your answer Eric.
> 
> > Using Rack::Timeout with Rainbows! instead of unicorn is probably a
> > better idea.
> 
> 99% of the requests are fast and can be served far below 300 ms.  Only
> a few type of requests need to stream lots of data.  Do you really think that
> unicorn isn't a good choice in this case and I should consider switching to
> something else (Rack::Timeout + Rainbows!, Puma or whatever) just for the
> sake of that 1%?

What Hongli said.  unicorn is only for sending fast responses.  You'll
run into scalability problems very quickly if unicorn is used for any
slow response.
_______________________________________________
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