[Mongrel] Design flaw? - num_processors, accept/close
rob at robmela.com
Tue Oct 16 08:30:28 EDT 2007
Alexey Verkhovsky wrote:
> On 10/15/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>> Tried Lucas Carlson's Dr. Proxy yet? Other solutions? Evented mongrel?
> HAProxy (and some other proxies smarter than mod_proxy_balancer)
> solves this problem by allowing to set the maximum number of requests
> outstanding to any node in the cluster.
But m_p_b is correct in this!!! It's the "max" attribute to BalancerMember.
It's just a pain to discover the correct combination of parameters!
> Setting it to 1 means that it
> will only ask a Mongrel instance to serve a request when it's not
> already doing so
But mpb IS doing this correctly, as you specify! It's a matter of
combining "max" and "acquire" attrs on BalancerMember. Perhaps the
thing that needs changing is documentation, making this the default mpb
behavior, or better documentation ( or all of the above! )
> . Which makes perfect sense with Rails
> (single-threaded), especially if you do have something else to serve
> static content in this setup.
> Setting num_processors to 1 is only possible when you have a proxy
> that can restrict itself from sending more than one request per
Which we do in m_p_b, via the "max" attribute to BalancerMember
> Otherwise, if I remember correctly, you replace occasional
> delays with HTTP 503s. Not a good trade-off.
The 503s would only be generated in the case of incorrect mpb
settings. A 503 "server busy" coming from the Mongrel back-end gives
developers and admins a better idea of what's really happening.
Consider: the back end has reached maximum capacity. Saying "Hey
503! I'm at max capacity" is better than the current action -- open and
close with no indication of what's wrong.
> Setting num_processors low has a positive side effect of restricting
> how far your Mongrel will grow in memory when put under strain even
> 5), just so that monitoring can hit it at the same time when load
> balancer does.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/416806fd/attachment.vcf
More information about the Mongrel-users