[Mongrel] Design flaw? - num_processors, accept/close

[Robert Mela]

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
> Mongrel.

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.
>
>   
Excellent idea!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rob.vcf
Type: text/x-vcard
Size: 116 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20071016/416806fd/attachment.vcf