fair load balancing?
amw at apple.com
Fri Jun 20 05:22:31 UTC 2008
On Jun 19, 2008, at 7:08 PM, Mark Smith wrote:
>> I'll admit I'm completely knew to Perlbal, but I don't understand how
>> verify_backend will work here.
>> I just ran Perlbal up last week, proxying http requests to Mongrel
>> I had "SET verify_backend = on" in my config file.
>> I still saw long-requests blocking subsequent requests.
>> Am I misunderstanding something?
> 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.
More information about the perlbal