Hi,
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.
Rainer
