httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Theo Schlossnagle <>
Subject Re: Working on some load balancing methods
Date Tue, 11 Jan 2005 16:08:05 GMT

On Jan 11, 2005, at 11:00 AM, Jim Jagielski wrote:
> Theo Schlossnagle wrote:
>> Having mod_backhand use mod_proxy isn't very difficult.  We 
>> implemented
>> that for a client.  I don't understand the comment about the web 
>> server
>> doing stuff.  mod_proxy sits inside apache and adheres to the same
>> limitations do to it architectural position as mod_backhand.
> Just that just because you *can* implement something in the
> web server, doesn't mean you *should* or *must*. A web server
> is part of one's web infrastructure, not its entirety.

I absolutely agree.  I misunderstood you.  It sounded like you were 
arguing against mod_backhand and for mod_proxy on the basis that the 
web server isn't the right place to be doing it...  As the both live in 
the web server proper, it seemed an awkward position.

If y'all want to build a good load balancer, use APR and stay our of 
the Apache server proper completely.  It would afford you the 
opportunity to scale better as much of the plumbing within Apache that 
guides it architectural design can be shed.

Graham and I talked about how to make mod_proxy "backhand capable" for 
some time.  Neither of us had time on our hands to look at it.  
mod_backhand isn't a proxy framework, it is a decision making framework 
that allows complex, adaptable decision making functions to be applied 
and a collaborative manner using the concept of peer-to-peer systems.  
The fact that the current version of mod_backhand has its own internal 
proxying code instead of using mod_proxy via the EAPI is simple a 
testament to its roots (outside of Apache).

I am not at all against making mod_proxy a good load balancer.  It 
would, however, be a shame to lose the innovations (if in concepts 
only) that has already occurred in a similar project.

// Theo Schlossnagle
// Principal Engineer --
// OmniTI Computer Consulting, Inc. --
// Ecelerity: fastest MTA on Earth

View raw message