fair load balancing?
Pedro Melo
melo at simplicidade.org
Fri Jun 20 10:16:10 UTC 2008
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?
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!
More information about the perlbal
mailing list