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 <[EMAIL PROTECTED]> wrote: > On Mon, Nov 17, 2008 at 10:36 PM, Zed A. Shaw <[EMAIL PROTECTED]> 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 > [email protected] > http://rubyforge.org/mailman/listinfo/mongrel-development > -- Evan Weaver _______________________________________________ Mongrel-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-development
