Mladen Turk wrote:
Bill Stoddard wrote:
1. Additional by business load balancing method
that will load balance on the actual load of the
beckend servers. The servers that have shorter reply
time will get more load.
+1 on the work, but I question the usefulness of this routing
algorithm. Does reply time (from the backend server)correlate with
resource utilization on the backend server in any but the most
contrived cases?
Yes, the algorithm is the average over the predefined amount of time.
Further more Rainer Jung (our newest Tomcat commiter) has done a
great job by rewriting most of the lb algos to be less spiky, so I
plan to port his work to mod_proxy_balancer.
Ok Mladen, thanks for the info. If the algorithm can account for things like hung applications in the backend
(which would cause the reply time to spike) and place different applications in different balancing pools to
keep one bad application from causing all traffic to be routed away from an otherwise available server, then
it begins to become a usable routing algorithm.
What are some other ways to intuit backend server performance other than 'reply time'? Some thoughts... It
would be pretty slick to drive code into mod_proxy (or mod_lb, whatever) which could cause the server to
'request' performance stats from a backend server; The backend server would have to recognize the 'request'
for performance stats and be able to respond by either adding a HTTP 'performance stat' header to the response
(e.g. X-Performance-Foo: bar) or encase the performance stat data in a multipart mime message along with the
response data. The proxy could gather the performance stat data out of the X-Performance-Foo header (or strip
out the performance part of the multi-part mime response) and use the performance stats any way it wanted.
Yea, I know there are packages out there that use lan multicast to exchange data like this.
Ok, now going completely over the top.... wouldn't it be nice if mod_proxy could request arbitrary meta data
(not just performance data)to be collected from backend servers; the backend servers obviously need to be able
to understand and decode requests. ARM sort of does this for things like response time of every piece of code
in a transaction path. I am thinking even more general. =>Any<= piece of information available to the backend
server could be consolidated in a mod_proxy instance and acted upon at the scope of an entire cluster. Think
debug data, performance data, QoS data, at whatever granularity needed (application, server, cluster).
Once mod_proxy has access to lots of interesting bits, it can be programmed to detect and respond to anomalous
application behaviors (what's considered "anomalous" is tunable and maybe is dynamically adjustable). Maybe it
autonomically collect problem determination data and send alerts to the sys admin when anomalies are detected
or adjusts it's operating characteristics in whatever manner the admin decides is appropriate.
Bill
Regards,
Mladen.
