# Apache 2.2 / mod\_proxy\_balancer / mongrel - only proxy to no

**URL:** <https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375>\
**Category:** Deployment\
**Created:** [January 25, 2007, 5:16pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375 "2007-01-25T17:16:52Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 25, 2007, 5:16pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/1 "2007-01-25T17:16:52Z")

</div>

Is there some way to only proxy to non-busy mongrel’s? I’m running 6  
mongrels, and if 1 is busy 1 out of every 6 next requests will stall.  
The other 5 mongrels could easily handle them quickly. I know the  
standard answer for long running tasks is a separate worker process, and  
that makes sense for really big long running tasks, but for 10-20 second  
or so pages it seems a lot of extra work to split the logic into  
multiple pieces if there is an easy way to not send more requests to a  
busy mongrel.

–  
Jack C.  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 25, 2007, 6:41pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/2 "2007-01-25T18:41:28Z")

</div>

On Jan 25, 5:16 pm, Jack C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Is there some way to only proxy to non-busy mongrel’s? I’m running 6  
> mongrels, and if 1 is busy 1 out of every 6 next requests will stall.  
> The other 5 mongrels could easily handle them quickly. I know the  
> standard answer for long running tasks is a separate worker process, and  
> that makes sense for really big long running tasks, but for 10-20 second  
> or so pages it seems a lot of extra work to split the logic into  
> multiple pieces if there is an easy way to not send more requests to a  
> busy mongrel.

Apache’s mod\_proxy module (and subsequently mod\_proxy\_balancer) backend  
monitoring is AFAIK limited to only being able to see if a proxy  
backend is down. It cannot monitor the load or “busy-ness” of the  
backend.

I know HA-Proxy and a bunch of hardware balancers does this, I don’t  
think nginx, lighttpd and pound does though?  
(someone should make a list somewhere with this kinda stuff ;))

So, either switch proxying software, or fix/workaround the original  
issue.

JS

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 25, 2007, 9:06pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/3 "2007-01-25T21:06:00Z")

</div>

On Jan 25, 2007, at 9:40 AM, Johan Sørensen wrote:

> > multiple pieces if there is an easy way to not send more requests  
> > think nginx, lighttpd and pound does though?  
> > (someone should make a list somewhere with this kinda stuff ;))
> 
> So, either switch proxying software, or fix/workaround the original  
> issue.
> 
> JS

Yeah Haproxy or any hardware load balancer can handle this. Apache,  
lighty and nginx don’t currently. But Igor, the author of nginx told  
me he will add a proxy-max-load directive so you coudl set it to 1  
and that mongrel would not get another request until it returns from  
the first and the requests would queue in nginx instead of in  
mongrel. Probably a week or two before nginx has this built in. This  
will give ngixn a significant advantage over apache and lighty.

Cheers-  
– Ezra Z.  
– Lead Rails Evangelist  
– removed\_email\_address@domain.invalid  
– Engine Y., Serious Rails Hosting  
– (866) 518-YARD (9273)

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 26, 2007, 1:35am UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/4 "2007-01-26T01:35:43Z")

</div>

On 1/25/07, Ezra Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> > > process, and  
> > > backend is down. It cannot monitor the load or “busy-ness” of the
> 
> ```
> Yeah Haproxy or any hardware load balancer can handle this. Apache,
> 
> ```
> 
> lighty and nginx don’t currently. But Igor, the author of nginx told  
> me he will add a proxy-max-load directive so you coudl set it to 1  
> and that mongrel would not get another request until it returns from  
> the first and the requests would queue in nginx instead of in  
> mongrel. Probably a week or two before nginx has this built in. This  
> will give ngixn a significant advantage over apache and lighty.

Litespeed also handles this internally.

Joe

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 26, 2007, 8:09am UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/5 "2007-01-26T08:09:13Z")

</div>

On Jan 25, 10:04 pm, Ezra Z. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> ```
> Yeah Haproxy or any hardware load balancer can handle this. Apache,
> 
> ```
> 
> lighty and nginx don’t currently. But Igor, the author of nginx told  
> me he will add a proxy-max-load directive so you coudl set it to 1  
> and that mongrel would not get another request until it returns from  
> the first and the requests would queue in nginx instead of in  
> mongrel. Probably a week or two before nginx has this built in. This  
> will give ngixn a significant advantage over apache and lighty.

That’s very cool, Ezra. Do you have any inside knowledge about how  
nginx will determine the load of a mongrel? Also, will it work to route  
around dead mongrels?

//jarkko

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 26, 2007, 7:02pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/6 "2007-01-26T19:02:19Z")

</div>

On Jan 25, 2007, at 11:08 PM, Jarkko L. wrote:

> That’s very cool, Ezra. Do you have any inside knowledge about how  
> nginx will determine the load of a mongrel? Also, will it work to  
> route  
> around dead mongrels?
> 
> //jarkko

Here is a quote from Igor about this feature:

"I plan to add someting like this:

```
 upstream name {
     server host:9000 max_conn=5 max_wait=100 wait_time=60s;
 }

```

"

So for mongrel you could set the max\_conn to 1. That would make sure  
no mongrel gets another request until it returns from whatever it’s  
doing.

Cheers-  
– Ezra Z.  
– Lead Rails Evangelist  
– removed\_email\_address@domain.invalid  
– Engine Y., Serious Rails Hosting  
– (866) 518-YARD (9273)

---

<div class="post-metadata">

**Author:** ![giaco](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/a3d4f5/32.png) [@giaco](https://www.ruby-forum.com/u/giaco)\
**Post date:** [January 29, 2007, 3:20pm UTC](https://www.ruby-forum.com/t/apache-2-2-mod-proxy-balancer-mongrel-only-proxy-to-no/83375/7 "2007-01-29T15:20:25Z")

</div>

Ezra Z. wrote:

> ```
> On Jan 25, 2007, at 9:40 AM, Johan Sørensen wrote:
> ```
> 
> > ```
> > On Jan 25, 5:16 pm, Jack C.[\<removed\_email\_address@domain.invalid\>](mailto:removed_email_address@domain.invalid)wrote:
> > ```
> > 
> > > ```
> > > Is there some way to only proxy to non-busy 
> > > mongrel's? I'm running 6
> > > mongrels, and if 1 is busy 1 out of every 6 next requests will stall.
> > > The other 5 mongrels could easily handle them quickly. I know the
> > > standard answer for long running tasks is a separate worker
> > > process, and
> > > that makes sense for really big long running tasks, but for 10-20
> > > second
> > > or so pages it seems a lot of extra work to split the logic into
> > > multiple pieces if there is an easy way to not send more requests
> > > to a
> > > busy mongrel.
> > > ```
> > 
> > ```
> > Apache's mod_proxy module (and subsequently 
> > mod_proxy_balancer)
> > backend
> > monitoring is AFAIK limited to only being able to see if a proxy
> > backend is down. It cannot monitor the load or "busy-ness" of the
> > backend.
> > 
> > I know HA-Proxy and a bunch of hardware balancers does this, I don’t  
> > think nginx, lighttpd and pound does though?  
> > (someone should make a list somewhere with this kinda stuff ;))
> > 
> > So, either switch proxying software, or fix/workaround the original  
> > issue.
> > 
> > JS
> > ```
> 
> ```
> Yeah Haproxy or any hardware load balancer can handle this. Apache,  
> lighty and nginx don’t currently. But Igor, the author of nginx told  
> me he will add a proxy-max-load directive so you coudl set it to 1  
> and that mongrel would not get another request until it returns from  
> the first and the requests would queue in nginx instead of in  
> mongrel. Probably a week or two before nginx has this built in. This  
> will give ngixn a significant advantage over apache and lighty.
> ```

  
Thanks. That sounds ideal. I will definitely keep an eye open for this feature.  

> ```
> Cheers-  
> – Ezra Z.  
> – Lead Rails Evangelist  
> – [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> – Engine Y., Serious Rails Hosting  
> – (866) 518-YARD (9273)
> ```

  
  

```
--
Jack C.[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)
```
  
--~--~---------~--~----~------------~-------~--~----~  
You received this message because you are subscribed to the Google Groups "Deploying Rails" group.   
 To post to this group, send email to removed\_email\_address@domain.invalid   
 To unsubscribe from this group, send email to removed\_email\_address@domain.invalid   
 For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en   
 -~----------~----~----~----~------~----~------~--~---
