You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by snacktime <sn...@gmail.com> on 2006/09/25 08:20:18 UTC
creating new lbmethod for mod_proxy_balancer
I have very little C programming experience, but I've decided to
tackle adding another load balancing method to mod_proxy_balancer.
The reason for a new lbmethod is to have something that works nicely
with ruby on rails. Both ruby and rails are not thread safe, which
poses certain challenges. Right now the most popular way of hosting
rails apps is using Mongrel http://mongrel.rubyforge.org/. Mongrel is
a simple http server which loads and runs rails, but it can only
process one request at a time due to rails not being thread safe. So
a fairly good way to serve up rails is to have a cluster of mongrels
behind apache using balancer. The problem is when you have a mix of
short requests with longer requests. Mongrel will queue up
connections but can only service one at a time, so one mongrel might
have several slow requests queued up, and another mongrel might only
be serving one request.
So, what I'm trying to do is implement a new lbmethod that will only
proxy a request to a balance member that has no requests currently
being processed. If there are no more balance members available, I'm
thinking the best thing is to implement a short wait cycle until a
free mongrel is available, and possibly log a warning so you know that
you need to add more mongrels to the cluster, and more balance members
to apache.
Any advice or hints are more then welcome, especially if for whatever
reason this is going to get really complicated.
Chris
Re: creating new lbmethod for mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yeah, some sort of locking/mutexing should
really be available. mod_jk has simple
locking, but the default is not to lock, iirc.
Re: creating new lbmethod for mod_proxy_balancer
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/25/06, Ruediger Pluem <rp...@apache.org> wrote:
> After having a look in the code I am just wondering why we do not have any
> locks around when changing this shared data / do not use atomics when increasing
> e.g the value for the number of read bytes (worker->s->read). Is this correct?
That's a good question... To be entirely correct, I believe atomics
should be used (and it would have to be actual atomics, not the bogus
fallbacks based on a cache of mutexes we use if we don't have real
atomics on the platform).
-garrett
Re: creating new lbmethod for mod_proxy_balancer
Posted by Ruediger Pluem <rp...@apache.org>.
On 25.09.2006 16:43, Garrett Rooney wrote:
> On 9/25/06, Ruediger Pluem <rp...@apache.org> wrote:
>
>> On 25.09.2006 16:32, Garrett Rooney wrote:
>> > On 9/25/06, Jim Jagielski <ji...@jagunet.com> wrote:
>> >
>> >> Actually, I've added the 'busy' struct element which
>> >> could be used for that... The orig intent was to add
>> >> the mod_jk "busyness" LB method, but it would also
>> >> serve as a flag that the member is busy ;)
>> >>
>> >> As of now, neither Trunk or 2.2.x do anything with busy,
>> >> but that will change soon :)
>> >
>> >
>> > How is that flag shared across worker processes? Is that structure
>> > stored in shared memory or something?
>>
>> It is shared via the scoreboard along with all other worker
>> interprocess data
>> like status of the worker etc.
>
>
> Ahh, cool. That will come in handy for the fastcgi stuff if I ever
> get back to it...
After having a look in the code I am just wondering why we do not have any
locks around when changing this shared data / do not use atomics when increasing
e.g the value for the number of read bytes (worker->s->read). Is this correct?
Regards
Rüdiger
Re: creating new lbmethod for mod_proxy_balancer
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/25/06, Ruediger Pluem <rp...@apache.org> wrote:
> On 25.09.2006 16:32, Garrett Rooney wrote:
> > On 9/25/06, Jim Jagielski <ji...@jagunet.com> wrote:
> >
> >> Actually, I've added the 'busy' struct element which
> >> could be used for that... The orig intent was to add
> >> the mod_jk "busyness" LB method, but it would also
> >> serve as a flag that the member is busy ;)
> >>
> >> As of now, neither Trunk or 2.2.x do anything with busy,
> >> but that will change soon :)
> >
> >
> > How is that flag shared across worker processes? Is that structure
> > stored in shared memory or something?
>
> It is shared via the scoreboard along with all other worker interprocess data
> like status of the worker etc.
Ahh, cool. That will come in handy for the fastcgi stuff if I ever
get back to it...
-garrett
Re: creating new lbmethod for mod_proxy_balancer
Posted by Ruediger Pluem <rp...@apache.org>.
On 25.09.2006 16:32, Garrett Rooney wrote:
> On 9/25/06, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> Actually, I've added the 'busy' struct element which
>> could be used for that... The orig intent was to add
>> the mod_jk "busyness" LB method, but it would also
>> serve as a flag that the member is busy ;)
>>
>> As of now, neither Trunk or 2.2.x do anything with busy,
>> but that will change soon :)
>
>
> How is that flag shared across worker processes? Is that structure
> stored in shared memory or something?
It is shared via the scoreboard along with all other worker interprocess data
like status of the worker etc.
Regards
Rüdiger
Re: creating new lbmethod for mod_proxy_balancer
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/25/06, Jim Jagielski <ji...@jagunet.com> wrote:
> Actually, I've added the 'busy' struct element which
> could be used for that... The orig intent was to add
> the mod_jk "busyness" LB method, but it would also
> serve as a flag that the member is busy ;)
>
> As of now, neither Trunk or 2.2.x do anything with busy,
> but that will change soon :)
How is that flag shared across worker processes? Is that structure
stored in shared memory or something?
-garrett
Re: creating new lbmethod for mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Sep 25, 2006, at 8:54 AM, Garrett Rooney wrote:
> On 9/25/06, snacktime <sn...@gmail.com> wrote:
>> I have very little C programming experience, but I've decided to
>> tackle adding another load balancing method to mod_proxy_balancer.
>> The reason for a new lbmethod is to have something that works nicely
>> with ruby on rails. Both ruby and rails are not thread safe, which
>> poses certain challenges. Right now the most popular way of hosting
>> rails apps is using Mongrel http://mongrel.rubyforge.org/.
>> Mongrel is
>> a simple http server which loads and runs rails, but it can only
>> process one request at a time due to rails not being thread safe. So
>> a fairly good way to serve up rails is to have a cluster of mongrels
>> behind apache using balancer. The problem is when you have a mix of
>> short requests with longer requests. Mongrel will queue up
>> connections but can only service one at a time, so one mongrel might
>> have several slow requests queued up, and another mongrel might only
>> be serving one request.
>>
>> So, what I'm trying to do is implement a new lbmethod that will only
>> proxy a request to a balance member that has no requests currently
>> being processed. If there are no more balance members available, I'm
>> thinking the best thing is to implement a short wait cycle until a
>> free mongrel is available, and possibly log a warning so you know
>> that
>> you need to add more mongrels to the cluster, and more balance
>> members
>> to apache.
>>
>> Any advice or hints are more then welcome, especially if for whatever
>> reason this is going to get really complicated.
>
> The major problem you're going to have is that you'll have to use some
> sort of shared memory (or a similar technique) to coordinate
> information between the various worker processes. Since Apache can
> run in multiprocess mode in addition to multithreaded modes you can't
> easily tell other workers "hey guys, I've got this one don't use it
> till I'm done". It'd be a useful problem to solve in a generic manner
> though, as the mod_proxy_fcgi module has a simlar problem.
>
Actually, I've added the 'busy' struct element which
could be used for that... The orig intent was to add
the mod_jk "busyness" LB method, but it would also
serve as a flag that the member is busy ;)
As of now, neither Trunk or 2.2.x do anything with busy,
but that will change soon :)
Re: creating new lbmethod for mod_proxy_balancer
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/25/06, snacktime <sn...@gmail.com> wrote:
> I have very little C programming experience, but I've decided to
> tackle adding another load balancing method to mod_proxy_balancer.
> The reason for a new lbmethod is to have something that works nicely
> with ruby on rails. Both ruby and rails are not thread safe, which
> poses certain challenges. Right now the most popular way of hosting
> rails apps is using Mongrel http://mongrel.rubyforge.org/. Mongrel is
> a simple http server which loads and runs rails, but it can only
> process one request at a time due to rails not being thread safe. So
> a fairly good way to serve up rails is to have a cluster of mongrels
> behind apache using balancer. The problem is when you have a mix of
> short requests with longer requests. Mongrel will queue up
> connections but can only service one at a time, so one mongrel might
> have several slow requests queued up, and another mongrel might only
> be serving one request.
>
> So, what I'm trying to do is implement a new lbmethod that will only
> proxy a request to a balance member that has no requests currently
> being processed. If there are no more balance members available, I'm
> thinking the best thing is to implement a short wait cycle until a
> free mongrel is available, and possibly log a warning so you know that
> you need to add more mongrels to the cluster, and more balance members
> to apache.
>
> Any advice or hints are more then welcome, especially if for whatever
> reason this is going to get really complicated.
The major problem you're going to have is that you'll have to use some
sort of shared memory (or a similar technique) to coordinate
information between the various worker processes. Since Apache can
run in multiprocess mode in addition to multithreaded modes you can't
easily tell other workers "hey guys, I've got this one don't use it
till I'm done". It'd be a useful problem to solve in a generic manner
though, as the mod_proxy_fcgi module has a simlar problem.
-garrett