From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Evan Weaver" Newsgroups: gmane.comp.lang.ruby.mongrel.devel Subject: Re: Mongrel 2.0 Date: Tue, 18 Nov 2008 11:22:44 -0500 Message-ID: References: <20081118053629.GK1405@zedshaw> Reply-To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1227025396 3420 80.91.229.12 (18 Nov 2008 16:23:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2008 16:23:16 +0000 (UTC) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Tue Nov 18 17:24:17 2008 Return-path: Envelope-to: gclrmd-mongrel-development@m.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=hfEApkvBGjJjeb6V7UXy3s1+TW0lkZLqRnwi4tQK5Kc=; b=ZxcXo1oKRcw9c1ECydAtAAAWtOcg2xwV+ppDCBCise8s6YUS/R6WCWORe0Un/Ehs5V YzFoNNK9qDdnqiV8RR38eG29aylMSfmWjejxbURVEEZNSeB0e/B1UHa5bK9J5iDFCPzo LXD2lbiaYTARoH5WsJ0KMY7PbuTjhczutwlYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=t9fzK594nq3i8FctWUfpjwqyuV7waanItM/w6iBR3RVfQrbxOkx9rweZ5OF2Q5Z3dK BY15qZ88lTebh1la9rYvMBDj3L8+Pv1T9Ypm5lU5a+ucqZQahHJqrzPU034Fo3T0E4kq ZamZQ06gosH11B8HSYFLygYWLGEDrveBAdFOk= In-Reply-To: Content-Disposition: inline X-Google-Sender-Auth: ec89f617c6dc8577 X-BeenThere: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.mongrel.devel:75 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1L2TMs-0005CQ-JX for gclrmd-mongrel-development@m.gmane.org; Tue, 18 Nov 2008 17:23:58 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id CB44518585C1; Tue, 18 Nov 2008 11:22:47 -0500 (EST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by rubyforge.org (Postfix) with ESMTP id 6F74018585C0 for ; Tue, 18 Nov 2008 11:22:45 -0500 (EST) Received: by yw-out-2324.google.com with SMTP id 9so1294836ywe.59 for ; Tue, 18 Nov 2008 08:22:45 -0800 (PST) Received: by 10.142.48.14 with SMTP id v14mr19865wfv.61.1227025364738; Tue, 18 Nov 2008 08:22:44 -0800 (PST) Received: by 10.143.18.8 with HTTP; Tue, 18 Nov 2008 08:22:44 -0800 (PST) List-Post: Whether the mongrel is overloaded such that responding further degrades service depends on whether you are blocked on local CPU or on a shared resource. In my experience, shared resource problems are more common. Evan On 11/18/08, Kirk Haines wrote: > On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw wrote: >> Very cool, nice work. One small comment... >> >> On Mon, Nov 17, 2008 at 03:32:33PM -0500, Evan Weaver wrote: >>> Hi Mongrels, >>> >>> - Error code instead of connection-close, as discussed earlier >> >> With this do you mean returning one of the many error codes in an HTTP >> response when the server is overloaded? >> >> I would recommend against that if that's the case. In theory it's nice >> to return an error code to clients that could be waiting. In practice, >> your queue is already overloaded, so taking more time to send a response >> to clients only adds to the problem. In a modern system this isn't such >> a big deal, but in Ruby it becomes a mess because of the file id limits >> in the select loop. > > In an overload situation, I think that just dropping the connection is > an acceptable thing to do, though. The mongrel is overloaded, so it > is a correct and beneficial response on the part of the proxy to > assume something is wrong with it, and to stop sending traffic to it > for a while. > > The use case for sending a response instead of just dropping the > connection is when the HTTP parser throws an exception because of > malformed HTTP. > > Currently that results in an immediate closed connection. The problem > there is that upstream proxies can assume that getting the connection > cut unexpectedly means that the mongrel itself has a problem. If that > proxy responds to this by removing that mongrel from the proxy > rotation for a period of time, one misbehaving client, whether > intentionally or unintentionally, can DOS a whole cluster. > > The fix is to just return a canned 400 response before closing. > > > Kirk Haines > _______________________________________________ > Mongrel-development mailing list > Mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver