httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "mark wolgemuth" <>
Subject possible integration into mod_proxy, mod_proxy_balancer of similar complementary load balancer module
Date Fri, 07 Dec 2007 21:39:58 GMT
I spoke with a couple of you at ApacheCon, and there was some interest
in pursuing a conversation about how load balancing in mod_proxy might
be advanced and/or extended by reusing, merging or just adding some of
the code we have. Thanks especially to Jim Jiglieski for your time.

code can be retrieved here:
or svn'ed from here:
svn checkout ath-read-only

a quick overview can be garnered from the slightly out of date docs,
especially directives:

The code base in question works very much like mod_proxy_balancer, but
differs in a couple key points, some here:

1) uses separate shared memory segment to store state tables (no
overlap on scoreboard), with configurable lock granularity, down to
row level

2) uses the destination "host" field of a ProxyPass / ProxyPassReverse
declaration to map incoming requests to target farms

3) allows statistics on members to be pushed to the lb via a simple
GET query, allowing for load balancing on arbitrary metrics such as
cpu, load average, or higher lvl data like open database connections
or JVM thread count, etc.

4) there is a mechanism, via secret key protected cookie, for member
servers to set instructions to change load balancing decisions (eg
move to another farm, be sticky, be sticky safely (stick as long as
server is up, but otherwise move)).

5) the configuration and distinction in the reverse proxy of systems
that are "down" vs "administratively offline" and the ability to
redirect selectively on this state

... and some others that can be further discussed.

I'd say in simple examination, that where the conception of
mod_proxy_balancer may be more network and content centric, this
design is more application server centric.

It could be that you may want to just add it as an alternate and
complement to mod_proxy_balancer, with a new name of mod_proxy_??, or
that we get together on bringing this projects into a single expanded
lb solution.

This code has been out in the wild on AP2 license for a number of
years, and has >5 yrs production deployment in high traffic with
extensive performance testing and code path analysis, so its pretty
robust. My company pays me to support this code base, among other
things, so I can continue significant contributions, and have a few
developers here who could also assist.

Next steps for me, regardless, are to go through the code and
rationalize the function naming to fit in better with mod_proxy_* and
also to retire some code that is still in use from when this was
conceived as being potentially a standalone product; basically,
eliminating all our custom collections types in favor of apr tables,
lists, and hashes.

Any thoughts on this would be greatly appreciated.

--Mark Wolgemuth

Mark Wolgemuth

View raw message