Re: Increassing timeouts
Troex Nevelin wrote: > On Jan 15, 2013, at 21:44 , Eric Wong wrote: > > But seriously, who will wait 120s for a website to load? > > I have similar situation, in my case it's admin interface so admin > knows that some operations need time to process and will wait. > > Right now I'm running two packs of Unicorn instances - one for quick > and one for long requests. But most of the time long request pool is > idling and eating memory. Cranking up the timeout will improve its chances of being swapped out. If memory usage of an infrequently used instance is a concern. > My question: is possible to change Unicorn timeout per request from > Rails app? Middleware hook could be ok too. (not sure if it's possible > as I think timeout is set in master). Right, it's currently not possible to influence the master. And I'm not convinced it's the right way to go, either. What I've done in the past is to put the client in a periodic refresh loop (meta refresh or whatever tag it was) and have it poll the app while it was waiting for a long-running job to finish. I think it was (or still is) a common thing... Btw, Rubyforge delayed this email by over 3 weeks? But then again you responded to a 6 month old thread %x ___ 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: Increassing timeouts
On Jan 15, 2013, at 21:44 , Eric Wong wrote: > But seriously, who will wait 120s for a website to load? I have similar situation, in my case it's admin interface so admin knows that some operations need time to process and will wait. Right now I'm running two packs of Unicorn instances - one for quick and one for long requests. But most of the time long request pool is idling and eating memory. My question: is possible to change Unicorn timeout per request from Rails app? Middleware hook could be ok too. (not sure if it's possible as I think timeout is set in master). ___ 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: Increassing timeouts
On Jan 15, 2013, at 21:44 , Eric Wong wrote: > But seriously, who will wait 120s for a website to load? I have similar situation, in my case it's admin interface so admin knows that some operations need time to process and will wait. Right now I'm running two packs of Unicorn instances - one for quick and one for long requests. But most of the time long request pool is idling and eating memory. My question: is possible to change Unicorn timeout per request from Rails app? Middleware hook could be ok too. (not sure if it's possible as I think timeout is set in master). ___ 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: Increassing timeouts
In case you missed it, I responded to your original message: http://mid.gmane.org/20130115194408.ga30...@dcvr.yhbt.net ___ 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
Increassing timeouts
Hello there We use Unicorn in all of our production/staging web-apps, and we are very happy with it. But we also have one app which talks to a web-service via SOAP, and this web-service now takes longer than usual processing requests. To solve this situation we have increased the time-outs for unicorn and nginx (proxy_read_timeout and proxy_connect_timeout) from 30 to 120, and everything works fine this way (although I don't like it). My question is: having increased the time-out to 120 means this app is now considered slow (or sleepy) and should be run by Rainbow ? or is 120 still ok for Unicorn ? Thanks in advance ! Manuel P. ___ 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: Increassing timeouts
Manuel Palenciano Guerrero wrote: > Hello there > > We use Unicorn in all of our production/staging web-apps, and we are > very happy with it. But we also have one of the apps talking to a > web-service via SOAP, and this web-service now takes longer than usual > processing requests. To solve this situation we have increased the > time-outs for unicorn and nginx (proxy_read_timeout and > proxy_connect_timeout) from 30 to 120, and everything works fine this > way (although I don't like it). > > My question is: having increased the time-out to 120 means this app is > now considered slow (or sleepy) and should be run by Rainbow ? or is > 120 still ok for Unicorn ? As usual, it depends. If clients hitting other endpoints are able to access your site, you're fine... But seriously, who will wait 120s for a website to load? ___ 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
Increassing timeouts
Hello there We use Unicorn in all of our production/staging web-apps, and we are very happy with it. But we also have one of the apps talking to a web-service via SOAP, and this web-service now takes longer than usual processing requests. To solve this situation we have increased the time-outs for unicorn and nginx (proxy_read_timeout and proxy_connect_timeout) from 30 to 120, and everything works fine this way (although I don't like it). My question is: having increased the time-out to 120 means this app is now considered slow (or sleepy) and should be run by Rainbow ? or is 120 still ok for Unicorn ? Thanks in advance ! Manuel Palenciano ___ 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
