You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mohan2005 <mo...@roomsnet.com> on 2008/01/06 17:16:10 UTC
mod_jk "Busyness" algorithm and Node Health Check
Dear All;
If I am not wrong, the "Busyness" algorithm routes requests to workers by
checking their "Health"
What criteria constitutes as a "nodes" "Health"
and if so,
How is it determined (using the native JVM or else )
Thanks you
Regards
Mohan
--
View this message in context: http://www.nabble.com/mod_jk--%22Busyness%22-algorithm-and-Node-Health-Check-tp14650298p14650298.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk "Busyness" algorithm and Node Health Check
Posted by Rainer Jung <ra...@kippdata.de>.
Mohan2005 wrote:
> Hello Rainer;
>
> Thanks.
> So if I have it right, sorry if I keep repeating whats been stated already,
> all the load-balancer algorithms are not really checking node health as in
> JVM Memory usage, CPU usage or Threads used at any given time (which I
> believe is a feature in a future mod_jk ? ),
>
> Only checks the Network Latency (Network Response ) through Cping and Cpong
> methods as a nodes health as described in
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
Correct.
> Rainer Jung-3 wrote:
>> Hi Mohan,
>>
>> Mohan2005 schrieb:
>>> Dear All;
>>>
>>> If I am not wrong, the "Busyness" algorithm routes requests to workers
>>> by
>>> checking their "Health"
>>>
>>> What criteria constitutes as a "nodes" "Health"
>>> and if so,
>>> How is it determined (using the native JVM or else )
>> All balancing methods of mod_jk share common aspects:
>>
>> 1) Don't send requests to workers, which are in error
>>
>> Workers go into error state, whenever mod_jk detects a failure during
>> request processing with that worker.
>> Which failures depends on the jk configuration. Mostly they are timeouts
>> and network problems.
>>
>> 2) Use stickyness instead of load based balancing if not disabled
>>
>> 3) Decide about requests without sessions based on the load value of the
>> workers, which are not in error
>>
>> What's the load value?
>> That depends on the balancing method.
>>
>> - method "Request" (default): increase the load value of a worker by one
>> for each request send to the worker and divide by two all load values
>> every now and then (app. once a minute). So the load value is the
>> comulative number of requests handled by the worker with a envelope
>> curve that counts older requests less than more recent ones. This method
>> tries to keep total work balanced.
>>
>> - method "Session": the same as Request, but do only count a request, if
>> it didn't contain a session cookie or URL encoded session. It is not the
>> same as actually knowing how many sessions each backend has.
>>
>> - method "Busyness": load value is the number of requests currently
>> being processed by a worker. For example when load is low, most or all
>> workers will have load value "0". This method tries to keep concurrency
>> balanced. It will not be good in balancing total work.
>>
>> So: the health aspect is not special to method "Busyness". One could
>> argue, that if one node gets slow, the concurrency will go up soon, so
>> Busyness includes a good prevention for overload. On the other hand,
>> using "Request" with a reply_timeout will also lead to such a
>> prevention, because then a node that has overload will be put
>> temporarily into error state.
>>
>> Mod_jk has no internal knowledge of the backends state, like Memory,
>> Thread counts etc. It can only judge by the symptoms observed during the
>> response handling (no connect possible, no cpong answer to a cping,
>> response took longer than reply_timeout etc.).
>>
>> Whenever such a type of error is detected, the jk log should contain an
>> error log line with an indication of the type of error. With JkLogLevel
>> info you might get (info) log lines even if there is no hard error, but
>> in case of a real error, you will get additional information about the
>> root cause.
>>
>>> Thanks you
>>> Regards
>>> Mohan
>> Regards,
>>
>> Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk "Busyness" algorithm and Node Health Check
Posted by Mohan2005 <mo...@roomsnet.com>.
Hello Rainer;
Thanks.
So if I have it right, sorry if I keep repeating whats been stated already,
all the load-balancer algorithms are not really checking node health as in
JVM Memory usage, CPU usage or Threads used at any given time (which I
believe is a feature in a future mod_jk ? ),
Only checks the Network Latency (Network Response ) through Cping and Cpong
methods as a nodes health as described in
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
Regards
Mohan
Rainer Jung-3 wrote:
>
> Hi Mohan,
>
> Mohan2005 schrieb:
>> Dear All;
>>
>> If I am not wrong, the "Busyness" algorithm routes requests to workers
>> by
>> checking their "Health"
>>
>> What criteria constitutes as a "nodes" "Health"
>> and if so,
>> How is it determined (using the native JVM or else )
>
> All balancing methods of mod_jk share common aspects:
>
> 1) Don't send requests to workers, which are in error
>
> Workers go into error state, whenever mod_jk detects a failure during
> request processing with that worker.
> Which failures depends on the jk configuration. Mostly they are timeouts
> and network problems.
>
> 2) Use stickyness instead of load based balancing if not disabled
>
> 3) Decide about requests without sessions based on the load value of the
> workers, which are not in error
>
> What's the load value?
> That depends on the balancing method.
>
> - method "Request" (default): increase the load value of a worker by one
> for each request send to the worker and divide by two all load values
> every now and then (app. once a minute). So the load value is the
> comulative number of requests handled by the worker with a envelope
> curve that counts older requests less than more recent ones. This method
> tries to keep total work balanced.
>
> - method "Session": the same as Request, but do only count a request, if
> it didn't contain a session cookie or URL encoded session. It is not the
> same as actually knowing how many sessions each backend has.
>
> - method "Busyness": load value is the number of requests currently
> being processed by a worker. For example when load is low, most or all
> workers will have load value "0". This method tries to keep concurrency
> balanced. It will not be good in balancing total work.
>
> So: the health aspect is not special to method "Busyness". One could
> argue, that if one node gets slow, the concurrency will go up soon, so
> Busyness includes a good prevention for overload. On the other hand,
> using "Request" with a reply_timeout will also lead to such a
> prevention, because then a node that has overload will be put
> temporarily into error state.
>
> Mod_jk has no internal knowledge of the backends state, like Memory,
> Thread counts etc. It can only judge by the symptoms observed during the
> response handling (no connect possible, no cpong answer to a cping,
> response took longer than reply_timeout etc.).
>
> Whenever such a type of error is detected, the jk log should contain an
> error log line with an indication of the type of error. With JkLogLevel
> info you might get (info) log lines even if there is no hard error, but
> in case of a real error, you will get additional information about the
> root cause.
>
>> Thanks you
>> Regards
>> Mohan
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/mod_jk--%22Busyness%22-algorithm-and-Node-Health-Check-tp14650298p14663038.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: mod_jk "Busyness" algorithm and Node Health Check
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Mohan,
Mohan2005 schrieb:
> Dear All;
>
> If I am not wrong, the "Busyness" algorithm routes requests to workers by
> checking their "Health"
>
> What criteria constitutes as a "nodes" "Health"
> and if so,
> How is it determined (using the native JVM or else )
All balancing methods of mod_jk share common aspects:
1) Don't send requests to workers, which are in error
Workers go into error state, whenever mod_jk detects a failure during
request processing with that worker.
Which failures depends on the jk configuration. Mostly they are timeouts
and network problems.
2) Use stickyness instead of load based balancing if not disabled
3) Decide about requests without sessions based on the load value of the
workers, which are not in error
What's the load value?
That depends on the balancing method.
- method "Request" (default): increase the load value of a worker by one
for each request send to the worker and divide by two all load values
every now and then (app. once a minute). So the load value is the
comulative number of requests handled by the worker with a envelope
curve that counts older requests less than more recent ones. This method
tries to keep total work balanced.
- method "Session": the same as Request, but do only count a request, if
it didn't contain a session cookie or URL encoded session. It is not the
same as actually knowing how many sessions each backend has.
- method "Busyness": load value is the number of requests currently
being processed by a worker. For example when load is low, most or all
workers will have load value "0". This method tries to keep concurrency
balanced. It will not be good in balancing total work.
So: the health aspect is not special to method "Busyness". One could
argue, that if one node gets slow, the concurrency will go up soon, so
Busyness includes a good prevention for overload. On the other hand,
using "Request" with a reply_timeout will also lead to such a
prevention, because then a node that has overload will be put
temporarily into error state.
Mod_jk has no internal knowledge of the backends state, like Memory,
Thread counts etc. It can only judge by the symptoms observed during the
response handling (no connect possible, no cpong answer to a cping,
response took longer than reply_timeout etc.).
Whenever such a type of error is detected, the jk log should contain an
error log line with an indication of the type of error. With JkLogLevel
info you might get (info) log lines even if there is no hard error, but
in case of a real error, you will get additional information about the
root cause.
> Thanks you
> Regards
> Mohan
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org