httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: mod_proxy_balancer/mod_proxy_ajp TODO
Date Mon, 19 Jun 2006 20:06:02 GMT

sorry for breaking the mail threading, but I read this list offline 
before and just subscribed to it now.

I would like to release mod_jk 1.2.16 soon, but as soon as that release 
looks good, I would be willing to help syncing features between 
mod_proxy_balancer/mod_proxy_ajp and mod_jk.

Comments see inline.

> 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.

Thanks Mladen for giving credits to my patches. Still more to do.

Concerning Busyness: This is an interesting strategy for load balancing, 
when parallelity is a critical ressource. I know cases, where people do 
huge downloads via tomcat and then it's interesting to balance the 
amount of parallel downloads.

> 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.

You could either use Busyness as a strategy, or you can set 
reply_timeouts, so that an application getting very slow will put the 
worker into error state. Such a worker will only be retried once a minute.

With the head code of mod_jk you can now define several workers for the 
same Tomcat target and still use stickyness (needed by most 
applications). E.g. each context could get its own balancer with it's 
own error states, load balancing etc. For this you need to use the new 
attribute jvm_route. Before, the name of the worker had to be equal to 
the jvmRoute attribute on the tomcat side to make stickyness work.

> 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.

It would be definitely great to establish a meta data communication 
channel between Apache and Tomcat. Two interesting use cases would be

- load status
- available contexts

Especially the second thing would be great for automatically managing 
mod_jk routing information (JkMount).

> Bill
>> Regards,
>> Mladen.


View raw message