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: AS14383 205.234.109.0/24 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,RP_MATCHES_RCVD shortcircuit=no autolearn=unavailable version=3.3.2 X-Original-To: archivist@yhbt.net Delivered-To: archivist@dcvr.yhbt.net Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by dcvr.yhbt.net (Postfix) with ESMTP id B4A2E21070 for ; Sat, 1 Oct 2011 04:10:44 +0000 (UTC) Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 353B6185838A; Sat, 1 Oct 2011 00:10:44 -0400 (EDT) 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 F0265185838C for ; Sat, 1 Oct 2011 00:06:08 -0400 (EDT) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 1BA662106F; Sat, 1 Oct 2011 04:06:08 +0000 (UTC) Date: Sat, 1 Oct 2011 04:06:07 +0000 From: Eric Wong To: unicorn list Subject: Re: large uploads Message-ID: <20111001040607.GB22604@dcvr.yhbt.net> References: <20110929184711.GA21222@dcvr.yhbt.net> <20110929205453.GA15148@dcvr.yhbt.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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 John Joseph Bachir wrote: > So buffering the entire request and then sending it to the backend is > the default behavior of HttpUpstreamModule? That's fascinating. It > almost seems like that's a bad design choice, because it inhibits the > possibility of parallel work being done as the request comes in (like, > it's the opposite of how unix pipes work). Yes, exactly. It's a design trade-off; if a client is uploading slowly (whether intentionally or maliciously) the process-per-client model of Unicorn is /extremely/ inefficient and will easily be shut down by slow clients. If you want to be able to process uploads in a Rack application while the client is uploading, you'd have to ensure your app is thread-safe and use Rainbows! + ThreadSpawn/ThreadPool. _______________________________________________ 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