unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Devin Ben-Hur <dbenhur@whitepages.com>
To: "Michael Fischer" <mfischer@zendesk.com>,
	"Bráulio Bhavamitra" <braulio@eita.org.br>
Cc: unicorn-public <unicorn-public@bogomips.org>
Subject: Re: Reserved workers not as webservers
Date: Thu, 9 Oct 2014 10:14:41 -0700	[thread overview]
Message-ID: <5436C281.30309@whitepages.com> (raw)
In-Reply-To: <CABHxtY7nRPP50a+-Ok02pDW3dJWA0CJc9C5hq+8e8wP+rBt57A@mail.gmail.com>

On 10/9/14, 9:45 AM, Michael Fischer wrote:
> On Thu, Oct 9, 2014 at 5:24 AM, Bráulio Bhavamitra <braulio@eita.org.br> wrote:
> I'm quite amazed of how preloading and fork and reduce memory usage.
>> Making it use even less memory and restarting the app faster, the next
>> step would be incorporate other daemons (also part of the app, in my
>> case delayed_job and feed-updater) AS unicorn workers.
> As your friendly neighborhood service engineer, my experience is that
> separating the concerns (keeping asynchronous processors separate from your
> synchronouous web services) is worth the additional memory and processor
> cost.  The two usually don't scale at the same rate, and you want to keep
> your failure domains separate as well: you don't want a bug in the async
> processor cause your web server to crash as well.   And let's not even get
> into the programming and maintenance challenges.

Excellent points Michael.  But to Bráulio's original request, it would 
be lovely to factor out the clean and robust process management parts of 
unicorn (daemonization, pidfile-mgmt, pre-load, fork, reap, signaling) 
separate from the HTTP/Rack server.  This would give us a robust 
supervisor for asynchronous workers that reduce memory footprint with 
CoW and responds to a well understood set of signals for management.

  reply	other threads:[~2014-10-09 17:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-09 12:24 Reserved workers not as webservers Bráulio Bhavamitra
2014-10-09 16:45 ` Michael Fischer
2014-10-09 17:14   ` Devin Ben-Hur [this message]
2014-10-09 17:17     ` Michael Fischer
2014-10-09 17:34     ` Eric Wong
2014-10-09 18:06       ` Bráulio Bhavamitra
2014-10-09 18:15         ` Eric Wong
2014-10-11  3:35           ` Bráulio Bhavamitra
2014-10-13  0:10             ` Bráulio Bhavamitra
2014-10-09 18:29     ` Bráulio Bhavamitra
2014-10-09 17:43   ` Bráulio Bhavamitra
2014-10-09 17:59     ` Michael Fischer
2014-10-09 18:01       ` Bráulio Bhavamitra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5436C281.30309@whitepages.com \
    --to=dbenhur@whitepages.com \
    --cc=braulio@eita.org.br \
    --cc=mfischer@zendesk.com \
    --cc=unicorn-public@bogomips.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).