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 EC6A81F438 for ; Mon, 29 Oct 2012 18:45:58 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 671212E075; Mon, 29 Oct 2012 18:45:58 +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 578CA2E074 for ; Mon, 29 Oct 2012 18:45:51 +0000 (UTC) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 7F4471F42C; Mon, 29 Oct 2012 18:45:49 +0000 (UTC) Date: Mon, 29 Oct 2012 18:45:49 +0000 From: Eric Wong To: unicorn list Subject: Re: Combating nginx 499 HTTP responses during flash traffic scenario Message-ID: <20121029184549.GA9690@dcvr.yhbt.net> References: 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 Tom Burns wrote: > We're looking at potential solutions to this problem, including: > - modifying unicorn to select() on the client connection after reading > the request, to see if it's been closed upstream, and avoid calling > the app. You should be able to get the socket out of Unicorn::TeeInput/Unicorn::StreamInput object via: env["rack.input"].instance_variable_get(:@socket) Make sure you don't have other middleware which wraps rack.input such as Rack::Lint. I highly doubt the ivar name will change in the future. If you're accepting uploads, you (or your app framework) will need to drain the socket of upload data, first (Rails does this for you, I think). > - Replacing nginx with haproxy and queuing connections there. This > goes against the nginx recommendation at > http://unicorn.bogomips.org/PHILOSOPHY.html Haproxy is fine as long as you have nginx /somewhere/ in between unicorn and clients. You have some extra overhead in data copying, but it could save you cycles... I'm unsure about the ordering, however: a) nginx -> haproxy -> unicorn b) haproxy -> nginx -> unicorn Though, I suspect a) will be better. > Any input would be appreciated. I'd love to hear back on how you eventually solve this, too :> _______________________________________________ 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