stop/start workers "by need"

stop/start workers "by need"

[Anton A. Vesnin]

Hello to everybody.
I making shared hosting for rails and rack applications. For app. server i 
userd phusion passenger, but after some issues with that, want to migrate to 
unicorn. 

Is there any way to make unicorn stop all workers and start them on first 
request? It'll be really great to have this opportunity. 

>No subscription is needed to post to the mailing list, let us know that we 
need to Cc: replies to you if you’re unsubscribed.
Reply with Cc:, pleace. Thank you.

--
With best regards.
_______________________________________________
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: stop/start workers "by need"

[Eric Wong]

"Anton A. Vesnin" <antonvesnin@gmail.com> wrote:
> Hello to everybody.
> I making shared hosting for rails and rack applications. For app. server i 
> userd phusion passenger, but after some issues with that, want to migrate to 
> unicorn. 
> 
> Is there any way to make unicorn stop all workers and start them on first 
> request? It'll be really great to have this opportunity. 

Hi Anton, there's no current way to do this.

Unlike Apache/Passenger, Unicorn should only be tuned for backend
requirements, never to actual connected clients.  Unicorn isn't too
different from prefork Apache when serving requests, it's just the
"marketing" for Unicorn focuses _very_ strongly on its limitations :)

On a memory-constrained box, maybe tailing logs or similar and sending
TTIN/TTOU signals to increment/decrement workers as needed can work.  A
smarter version of this would even recognize which endpoints are more/less
expensive and tune the workers accordingly.

A dumb version of this would just be a cronjob that
increments/decrements worker depending on the time of day.  If you're
running batch processes at off hours, maybe the dumb version is all you
need :)

I'm strongly against having this logic in Unicorn itself since apps
behave wildly differently depending on how they're implemented.  And
most deployments I've supported over the years were better off with
fixed/dedicated resources and letting the OS manage things.

> Reply with Cc:, pleace. Thank you.

-- 
Eric Wong
_______________________________________________
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: stop/start workers "by need"

[Jamie Wilkinson]

On Oct 29, 2010, at 4:16 AM, "Anton A. Vesnin" <antonvesnin@gmail.com> wrote:

> Hello to everybody.
> I making shared hosting for rails and rack applications. For app. server i 
> userd phusion passenger, but after some issues with that, want to migrate to 
> unicorn. 
> 
> Is there any way to make unicorn stop all workers and start them on first 
> request? It'll be really great to have this opportunity. 

You'd need to keep a master running, but TTOU and TTIN signals let you arbitrarily increase and reduce the number of workers. I think disabling app preloading might shave some memory from the master as well

What issues were you having with passenger? Passenger and unicorn were created with quite different goals but I'd be curious if this works for you




> 
>> No subscription is needed to post to the mailing list, let us know that we 
> need to Cc: replies to you if you’re unsubscribed.
> Reply with Cc:, pleace. Thank you.
> 
> --
> With best regards.
> _______________________________________________
> 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
_______________________________________________
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