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