Re: creating new lbmethod for mod_proxy_balancer
On 9/25/06, snacktime [EMAIL PROTECTED] 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
Re: creating new lbmethod for mod_proxy_balancer
On Sep 25, 2006, at 8:54 AM, Garrett Rooney wrote: On 9/25/06, snacktime [EMAIL PROTECTED] 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
On 9/25/06, Jim Jagielski [EMAIL PROTECTED] 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
On 25.09.2006 16:43, Garrett Rooney wrote: On 9/25/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 25.09.2006 16:32, Garrett Rooney wrote: On 9/25/06, Jim Jagielski [EMAIL PROTECTED] 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
On 9/25/06, Ruediger Pluem [EMAIL PROTECTED] 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
Yeah, some sort of locking/mutexing should really be available. mod_jk has simple locking, but the default is not to lock, iirc.
