Increassing timeouts

Increassing timeouts

[Manuel Palenciano Guerrero]

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

Re: Increassing timeouts

[Eric Wong]

Manuel Palenciano Guerrero <mpalenciano@gmail.com> 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

[Manuel Palenciano Guerrero]

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

[Eric Wong]

In case you missed it, I responded to your original message:
http://mid.gmane.org/20130115194408.GA30869@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

Re: Increassing timeouts

[Troex Nevelin]

On Jan 15, 2013, at 21:44 , Eric Wong <normalperson@yhbt.net> 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

[Troex Nevelin]

On Jan 15, 2013, at 21:44 , Eric Wong <normalperson@yhbt.net> 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

[Eric Wong]

Troex Nevelin <list@mrtech.ru> wrote:
> On Jan 15, 2013, at 21:44 , Eric Wong <normalperson@yhbt.net> 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