From: "Evan Weaver" <evan-72XWLPH10WVXUHR/Jj/Uug@public.gmane.org>
Subject: Re: Mongrel 2.0
Date: Tue, 18 Nov 2008 11:22:44 -0500 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
On 11/18/08, Kirk Haines <wyhaines-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> 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
next prev parent reply other threads:[~2008-11-18 16:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 20:32 Evan Weaver
[not found] ` <b6f68fc60811171232s46ba20ebh19ff2d499494622d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-17 20:33 ` Evan Weaver
[not found] ` <b6f68fc60811171233y7f103da0od5e875007f153f15-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-17 20:47 ` Ezra Zygmuntowicz
[not found] ` <B99E038D-E0E5-43D1-8DCA-08957639F2CF-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-11-17 22:55 ` Filipe Lautert
2008-11-18 5:36 ` Zed A. Shaw
2008-11-18 5:49 ` Evan Weaver
[not found] ` <b6f68fc60811172149i5d0c8261ldba15c02212d6a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20 2:31 ` Wayne Seguin
2008-11-18 14:59 ` Kirk Haines
[not found] ` <f4cd26df0811180659n218275a4hf06313ca8f48eed0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-18 16:22 ` Evan Weaver [this message]
2008-11-20 3:09 ` Luis Lavena
[not found] ` <71166b3b0811191909n6ad79b3cse89be4b9c50b8283-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20 4:39 ` Kirk Haines
[not found] ` <f4cd26df0811192039r7b96da46j5fde78edcc80cf91-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-20 5:54 ` Tony Arcieri
[not found] ` <c7e6b2b00811192154i1c2fb8f9g4cf70045c277e2a0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-21 18:03 ` Evan Weaver
2008-12-06 0:48 ` Eric Wong
replies disabled, historical list
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).