httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: mod_proxy_balancer/mod_proxy_ajp TODO
Date Mon, 19 Jun 2006 19:16:21 GMT
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.
> 





Mime
View raw message