On Son 24.09.2006 23:07, snacktime wrote:
>
>I was taking a look at the source for mod_proxy_balancer this evening,
>and it looks like the simplest solution to this whole problem is to
>just add another balance method. The functions that determine what
>balance member gets the next request are pre
I was taking a look at the source for mod_proxy_balancer this evening,
and it looks like the simplest solution to this whole problem is to
just add another balance method. The functions that determine what
balance member gets the next request are pretty short. I'm a pretty
bad C programmer, but I
> (*Laziness kicks in*) How do you find...which one of mongrel id idle?
It's a fantastically subtle and complicated algorithm. Not.
The main thread handles incoming connections, and then there's one thread
per worker. The main thread does this:
while request = server.accept
queue.push requ
On Don 21.09.2006 20:06, Paul Butcher wrote:
>> Have you ever use haproxy http://haproxy.1wt.eu/ ?!
>
>In a word, no :-)
>
>> He have the following feature which can help you:
>
>Thanks - sounds interesting. We'll give it a go!
Please let us/me know your experience ;-)
Thanks && Regards
Alex
___
> Have you ever use haproxy http://haproxy.1wt.eu/ ?!
In a word, no :-)
> He have the following feature which can help you:
Thanks - sounds interesting. We'll give it a go!
--
paul.butcher->msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
MSN: [EMAIL PROT
Jens Kraemer wrote:
> However, if I limit *one* of the mongrels to 1 connection at a time, I get
> this:
> pen -fdnr 9000 localhost:9001:1 localhost:9002
> Fast: 59
> Slow: 6
That's interesting! Thanks. I did try a similar configuration of
mod_proxy_balancer, but it didn't have the same effect. M
