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: X-Spam-Status: No, score=-2.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00, URIBL_BLOCKED shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: unicorn-public@bogomips.org Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 8161E1F49F; Wed, 4 Mar 2015 20:35:14 +0000 (UTC) Date: Wed, 4 Mar 2015 20:35:14 +0000 From: Eric Wong To: Sarkis Varozian Cc: Michael Fischer , unicorn-public Subject: Re: Request Queueing after deploy + USR2 restart Message-ID: <20150304203514.GA17826@dcvr.yhbt.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: Sarkis Varozian wrote: > On Wed, Mar 4, 2015 at 12:17 PM, Michael Fischer > wrote: > > > I'm not exactly sure how preload_app works, but I suspect your app is > > lazy-loading a number of Ruby libraries while handling the first few > > requests that weren't automatically loaded during the preload process. > > > > Eric, your thoughts? (top-posting corrected) Yeah, preload_app won't help startup speed if much of the app is autoloaded. Sarkis: which Ruby version are you running? IIRC, 1.9.2 had terrible startup performance compared to 1.9.3 and later in case you're stuck on 1.9.2 > That does make sense - I was looking at another suggestion from a user here > (Braulio) of running a "warmup" using rack MockRequest: > https://gist.github.com/brauliobo/11298486#file-unicorn-conf-rb-L77 > > The only issue I am having with the above solution is it is happening in > the before_fork block - shouldn't I warmup the connection in after_fork? If preload_app is true, you can warmup in before_fork; otherwise it needs to be after_fork. > If > I follow the above gist properly it warms up the server with the old > activerecord base connection and then its turned off, then turned back on > in after_fork. I think I am not understanding the sequence of events > there... With preload_app and warmup, you need to ensure any stream connections (DB, memcached, redis, etc..) do not get shared between processes, so it's standard practice to disconnect in the parent and reconnect in the child. > If this is the case, I should warmup and also check/kill the old > master in the after_fork block after the new db, redis, neo4j connections > are all created. Thoughts? I've been leaving killing the master outside of the unicorn hooks and doing it as a separate step; seemed too fragile to do it in hooks from my perspective.