fair load balancing?

Drew Wilson amw at apple.com
Fri Jun 20 13:27:15 UTC 2008

On Jun 20, 2008, at 3:16 AM, Pedro Melo wrote:

> Hi,
> On Jun 20, 2008, at 6:22 AM, Drew Wilson wrote:
>> On Jun 19, 2008, at 7:08 PM, Mark Smith wrote:
>>> verify_backend makes the process of connecting to a backend into  
>>> this:
>>> 1) start TCP connection to backend
>>> 2) on accept, send an "OPTIONS *" request
>>> 3) on 200 OK response, put backend in the pool
>>> The critical step is #2, and that's what makes this work.  Let's say
>>> you have Apache setup to MaxClients of 20, this will happen:
>>> * the first 20 requests come in, are assigned backends, and Perlbal
>>> uses them because they responded to OPTIONS *
>>> * the 21st connection Perlbal makes sits idle - beccause there is no
>>> Apache process to serve it
>>> * when one of the first 20 dies off, Apache will respond to the  
>>> 21st,
>>> and Perlbal spawns a new 21st
>> Thanks for the detailed explanation. Makes sense for Apache and  
>> other app servers that let child processes handle the requests.
>>> What ends up happening here is that Perlbal will use up exactly as
>>> many MaxClients as you specify - and no more.  Since (I assume) you
>>> have persistent connections to the backend, it works out perfectly.
>>> You can adjust the load on a server by adjusting MaxClients.  Of
>>> course, this does assume that on average, your requests are roughly
>>> equal in how much processing power it takes.
>>> I assume that Mongrel will let you do the same thing - specify how
>>> many processes to serve requests with.  If they use the same  
>>> behavior,
>>> then this approach will work out just as well for you as it does for
>>> Apache based systems.
>> Unfortunately, Mongrel doesn't spawn multiple processes to handle  
>> requests: it queues up each request and dispatches each request to  
>> Rails one at a time (since Rails is not threaded.) Mongrel doesn't  
>> support the OPTIONS method.
>> So instead of one Mongrel server managing several processes, we  
>> start up N mongrel app instances on each app server, and expect the  
>> balancer to handle the efficient routing. Sounds like is a bad  
>> expectation.
>> Now that you've explained this, it makes sense that there aren't  
>> that many balancers trying to balance each request: they expect the  
>> back-end to handle concurrent load.
>> I think our problem is with Mongrel. I will investigate using  
>> mod_rails, which will scale the way you describe.
> I don't know Mongrel so excuse me for piping up, but if Mongrel is  
> single threaded, it should not pass step 1 or 2 of the process Mark  
> detailed above.
> So Perlbal will not add more than one backend to the pool. Maybe you  
> need more Mongrel instances?
Well, I could add more instances, but in my testing, I see Perlbal  
distribute requests using a round-robin technique, so regardless of  
the number of instances, eventually my still-processing app instance  
gets handed a request.

I was hoping to find a balancer that kept track of open requests per  
back-end application and would forward requests to back-end  
applications without active requests.



More information about the perlbal mailing list