From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS33609 64.124.61.0/24 X-Spam-Status: No, score=-1.1 required=3.0 tests=AWL,BAYES_00,URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: unicorn-public@bogomips.org Received: from autodiscover.whitepages.com (mail0.w3data.com [64.124.61.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7DA8C1F89E for ; Thu, 9 Oct 2014 17:14:44 +0000 (UTC) Received: from devbenm0.corp.w3data.com (172.25.0.46) by ex4.corp.w3data.com (172.25.0.125) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 10:14:42 -0700 Message-ID: <5436C281.30309@whitepages.com> Date: Thu, 9 Oct 2014 10:14:41 -0700 From: Devin Ben-Hur User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Fischer , =?UTF-8?B?QnLDoXVsaW8gQmhhdmFt?= =?UTF-8?B?aXRyYQ==?= CC: unicorn-public Subject: Re: Reserved workers not as webservers References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.25.0.46] List-Id: On 10/9/14, 9:45 AM, Michael Fischer wrote: > On Thu, Oct 9, 2014 at 5:24 AM, BrĂ¡ulio Bhavamitra 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.