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: http://code.google.com/p/ath/downloads/list or svn'ed from here: svn checkout http://ath.googlecode.com/svn/trunk/ ath-read-only a quick overview can be garnered from the slightly out of date docs, especially directives: http://ath.sourceforge.net/mod_athena_doc/html/mod_athena_directives.html 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
