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: AS33070 50.56.128.0/17 X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: archivist@yhbt.net Delivered-To: archivist@dcvr.yhbt.net Received: from rubyforge.org (50-56-192-79.static.cloud-ips.com [50.56.192.79]) by dcvr.yhbt.net (Postfix) with ESMTP id 5B32C1F5B8 for ; Tue, 2 Apr 2013 22:36:49 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 27C0B2E0FA; Tue, 2 Apr 2013 22:36:50 +0000 (UTC) X-Original-To: mongrel-unicorn@rubyforge.org Delivered-To: mongrel-unicorn@rubyforge.org Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 7C5B82E0F0 for ; Tue, 2 Apr 2013 22:36:41 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 44F371F432; Tue, 2 Apr 2013 22:36:38 +0000 (UTC) Date: Tue, 2 Apr 2013 22:36:36 +0000 From: Eric Wong To: unicorn list Subject: Re: Unicorn hangs on POST request Message-ID: <20130402223636.GA16548@dcvr.yhbt.net> References: <513B5CFC.9080706@tnux.net> <20130309210227.GA29317@dcvr.yhbt.net> <20130311194912.GA11462@dcvr.yhbt.net> <0f19dafe5f9dde9423a2da669537838e.squirrel@voorstraat46.tnux.net> <20130311230157.GB26407@dcvr.yhbt.net> <20130402172410.GB16286@dcvr.yhbt.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: mongrel-unicorn@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mongrel-unicorn-bounces@rubyforge.org Errors-To: mongrel-unicorn-bounces@rubyforge.org Tom Pesman wrote: > > Probably not, at least it won't improve _consistency_ of performance > > without changing your app. > > > > The problem with buffering in Rainbows!+EM is the buffering happens after > > the work is distributed to different worker processes (Rainbows!+EM is > > still single-threaded). > > > > I don't believe there's a universal Rainbows! configuration which is > > good for most apps. With Rainbows!+EM, the buffering happens in a late > > stage, after workload is distributed, so you end up with head-of-queue > > blocking inside each process. > > > > All of the modules _without_ "rack.input streaming" will fully buffer > > responses (similar to how Rainbows!+EM) does it: > > http://rainbows.rubyforge.org/Summary.html > > > > However, CoolioThread{Pool/Spawn} should help you with the work load > > distribution problem if your app is thread-safe, but these both do body > > buffering. > > > > However, the multithreaded options _with_ "rack.input streaming" still > > give pretty good performance and let you get around the workload > > distribution problem of the single-threaded + internal buffering > > options. You'll reduce disk seek overhead with input streaming. > > > > For reference, nginx+unicorn is single-threaded, but with external > > buffering (nginx does the buffering, not unicorn). > > Thank you for your extensive response! > > To verify my thoughts on this, if I want to prevent the head-of-queue > blocking behaviour, I need to take a module without > rack.input_streaming. But we need to make sure the body is buffered > before it's given to a worker. On which property do I select the > correct module? Erm, no. You'll have head-of-queue blocking behavior with any single-threaded Rainbows! option and worker_connections > 1 Unless you rely on Cool.io or EM-specific features in your app, :EventMachine and :Coolio (and :Epoll/:XEpoll for Linux-only) are the same from an app-perspective in Rainbows! Using multi-threaded application dispatch (CoolioThread{Pool,Spawn}) will mitigate and reduce head-of-queue blocking. Likewise for using XEpollThreadPool/XEpollThreadSpawn (all the *Epoll* stuff is Linux-only) Alternatively, you won't get _any_ head-of-queue blocking in a multi-threaded app, you can use Thread{Pool,Spawn}. Sorry for the confusion. > Are Coolio modules still a sensible choice as the Coolio project isn't > actively maintained? Fwiw, Cool.io works pretty well in my experience. Last I checked, EM still had a problem by calling close(2) directly instead of rb_io_close(), triggering Errno::EBADF. There's a bug opened by somebody on the ruby-core team, but I'm not sure if it ever got resolved... I can also help fix Cool.io bugs since it's written in C, but I can't fix EM bugs: C++ is too big for my tiny brain. _______________________________________________ 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