httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <darryl-mailingli...@netbauds.net>
Subject Re: mod_proxy_balancer/mod_proxy_ajp TODO
Date Thu, 22 Jun 2006 13:53:50 GMT
Henri Gomez wrote:
> The TomcatoMips indicator was just something to tell that it's not the
> raw CPU power which is important, but the estimated LOAD capacity of
> an instance.


But its still apache working out TomcatoMips.  I think that approach is 
still flawed.

I'm saying only the server end of the AJP knows the true situation.  The 
current setup presumes that the running apache instance has all the 
facts necessary to determine balancing.  When all it knows about is the 
work it has given the backend and the work rate its betting it back.


I'm thinking both ends apache and tomcat should make load calculations 
based on that they know at hand.  As far as I know there is no provision 
in the AJP to announce "Willingness to serve".  Both ends should feed 
their available information and configuration biases it into their 
respective algorithm and come out with a result that can be compared 
against each other.  The worker would then announce as necessary (there 
maybe a minimum % change to damper information flap) down the connector 
the info to apache.  There probably need to be a random magic number and 
wrapping sequence number in the packet to help the apache end spot 
obvious problems.

This would allow kernel load avg/io load (and anything else) to be 
periodically taken into account at the tomcat end.  It would be expected 
that each member of the backend tomcat cluster is using the same 
algorithm to announce willingness.  Otherwise you get disparity when 
apache comes to make a decision.


So I suppose its just the framework to allow an LB worker to announce 
its willingness to serve I am calling for here.  Not any specific 
algorithm, that issue can be toyed with until the end of time.


An initial implementation would need to experiment and work out:
  * How that willingess value impacts/biases the existing apache LB 
calculations.
  * Guidelines on how to configure algorithm at each end up based on 
known factors (like CPUs, average background workload, relative IO 
performance).

I'm thinking with that you can hit the widest audience to make a usable 
default without giving much thought to configuration.  The type of 
approach kernels make these days, you only have to tweak and think about 
configuration in extreme scenarios but for the most it works well out of 
the box.


Darryl

Mime
View raw message