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/08 15:33:24 UTC
Busyness Method and others...
Hello!
The documentation says the following on the Busyness Method...
QUOTE
If set to B[usyness] the balancer will pick the worker with the lowest
current load, based on how many requests the worker is currently serving.
This number is divided by the workers lbfactor, and the lowest value (least
busy) worker is picked. This method is especially interesting, if your
request take a long time to process, like for a download application.
END QUOTE
What is defined as "take a long time", is it 30 sec, 40 sec, or more ?
and
from the clarifications I have got from this forum, the nodes "load" is
determined by it network latency using cping and cping. These I believe are
used by all load-balancer methods to determine a nodes health. So checking
the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or the
Traffic are just checking the counters of a node that is more active than
the other nodes.
Essentially what all these methods does is check a node's health by cping,
cping (Network latency) , and if it responds in good time, then check either
the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least
'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or
"Bytes IN/OUT" if "Traffic" method is used.
Is this summary of mod_jk in non-technical perspective accurate ??
Thanks
Regards
Mohan
--
View this message in context: http://www.nabble.com/Busyness-Method-and-others...-tp14690721p14690721.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: Busyness Method and others...
Posted by Mohan2005 <mo...@roomsnet.com>.
Great information.
This was what we were looking for.
This will help us a lot in future changes to our cluster and node
infrastructure.
Thank you very much.
Regards
Mohan
Rainer Jung-3 wrote:
>
> Mohan2005 wrote:
>> Hello Rainer;
>>
>> Thanks again for taking the time and for the information.
>>
>> if I quote you
>> "
>> Who told you that? cping/cpong have nothing to do with load decisions.
>> They only help in deciding, if a worker is in error status or not. Load
>> is distributed between all nodes that are not in error. To which of
>> those nodes a request goes is not decided by cping cpong.
>> "
>>
>>
>> But the million dollar question :-) is , if cping,cpong does not
>> determine a
>> nodes HEALTH OR LOAD as you put it, how is the LOAD on a node determined
>
> It *does* influence Health status, but not load status.
>
>> (what is used to monitor the health/load of nodes) technically by the
>
> Health: independant of method. Always: timeouts (if configured,
> socket_timeout, cping/cpong=connect_timeout and prepost_timeout,
> response time=reply_timeout, max_reply_timeouts, fail_on_status,
> recovery_options, see
>
> http://tomcat.apache.org/connectors-doc/reference/workers.html
>
> For all healthy ones: if lb has sticky_sessions and there is a session
> with a route coming with the request, do not balance but use the best
> worker w.r.t the session (but only from the healthy ones): The result is
> influenced by activation, the worker name, route, redirect, domain (and
> I think distance).
>
> If sticky, but all allowed workers are not healthy and
> sticky_session_force: error
>
> Else or if not sticky: pure balancing (between the healthy workers)
> influenced by activation, and lb_factor.
>
> Balancing itself choses the worker with the lowest lb_value. How do we
> get an lb_value. I cite myself:
>
> =======
> - 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.
>
> =======
>
> and finally (I forgot in the original mail)
>
> - method "Traffic": Like request, but for each request do not increment
> by one, instead increment by the number of bytes transferred to the
> backend for the request plus receuved from the backend with the response.
>
>> methods please?
>>
>> Thanks and Best Regards
>> Mohan
>
>
> Regards,
>
> Rainer
>
>>
>> Rainer Jung-3 wrote:
>>> Mohan2005 schrieb:
>>>> Hello!
>>>>
>>>> The documentation says the following on the Busyness Method...
>>>>
>>>> QUOTE
>>>> If set to B[usyness] the balancer will pick the worker with the lowest
>>>> current load, based on how many requests the worker is currently
>>>> serving.
>>>> This number is divided by the workers lbfactor, and the lowest value
>>>> (least
>>>> busy) worker is picked. This method is especially interesting, if your
>>>> request take a long time to process, like for a download application.
>>>> END QUOTE
>>>>
>>>> What is defined as "take a long time", is it 30 sec, 40 sec, or more ?
>>> Let us rephrase this. Busyness is especially useful, if the number of
>>> parallel requests you can handle is your limiting factor. Suppose you
>>> need to handle very high concurrency, like e.g. 10.000 parallel
>>> requests. Then you might come close to how many connections your
>>> components (OS, web server, Tomcat, etc.) can handle and you need to
>>> balance with respect to the expensive ressource "connections" instead of
>>> CPU etc.
>>>
>>> Now how does parallelity relate to long running requests?
>>>
>>> Parallelity = Throughput * ResponseTime
>>>
>>> So given some fixed throughput, parallelity grows proportional to
>>> reponse times. Talking about long response times is thus a simplified
>>> rephrasing of talking about high concurrency.
>>>
>>> If you have 10 request per second (not a high load), but the response
>>> time is 5 minutes, then you will end up with about 3.000 parallel
>>> requests and this could be a good scenario for busyness method.
>>>
>>>> and
>>>> from the clarifications I have got from this forum, the nodes "load" is
>>>> determined by it network latency using cping and cping. These I believe
>>>> are
>>> Who told you that? cping/cpong have nothing to do with load decisions.
>>> They only help in deciding, if a worker is in error status or not. Load
>>> is distributed between all nodes that are not in error. To which of
>>> those nodes a request goes is not decided by cping cpong.
>>>
>>>> used by all load-balancer methods to determine a nodes health. So
>>>> checking
>>>> the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or
>>>> the
>>>> Traffic are just checking the counters of a node that is more active
>>>> than
>>>> the other nodes.
>>>>
>>>> Essentially what all these methods does is check a node's health by
>>>> cping,
>>>> cping (Network latency) , and if it responds in good time, then check
>>>> either
>>> yes
>>>
>>>> the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least
>>>> 'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or
>>>> "Bytes IN/OUT" if "Traffic" method is used.
>>> yes
>>>
>>>> Is this summary of mod_jk in non-technical perspective accurate ??
>>>>
>>>>
>>>> Thanks
>>>> 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/Busyness-Method-and-others...-tp14690721p14715235.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: Busyness Method and others...
Posted by Rainer Jung <ra...@kippdata.de>.
Mohan2005 wrote:
> Hello Rainer;
>
> Thanks again for taking the time and for the information.
>
> if I quote you
> "
> Who told you that? cping/cpong have nothing to do with load decisions.
> They only help in deciding, if a worker is in error status or not. Load
> is distributed between all nodes that are not in error. To which of
> those nodes a request goes is not decided by cping cpong.
> "
>
>
> But the million dollar question :-) is , if cping,cpong does not determine a
> nodes HEALTH OR LOAD as you put it, how is the LOAD on a node determined
It *does* influence Health status, but not load status.
> (what is used to monitor the health/load of nodes) technically by the
Health: independant of method. Always: timeouts (if configured,
socket_timeout, cping/cpong=connect_timeout and prepost_timeout,
response time=reply_timeout, max_reply_timeouts, fail_on_status,
recovery_options, see
http://tomcat.apache.org/connectors-doc/reference/workers.html
For all healthy ones: if lb has sticky_sessions and there is a session
with a route coming with the request, do not balance but use the best
worker w.r.t the session (but only from the healthy ones): The result is
influenced by activation, the worker name, route, redirect, domain (and
I think distance).
If sticky, but all allowed workers are not healthy and
sticky_session_force: error
Else or if not sticky: pure balancing (between the healthy workers)
influenced by activation, and lb_factor.
Balancing itself choses the worker with the lowest lb_value. How do we
get an lb_value. I cite myself:
=======
- 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.
=======
and finally (I forgot in the original mail)
- method "Traffic": Like request, but for each request do not increment
by one, instead increment by the number of bytes transferred to the
backend for the request plus receuved from the backend with the response.
> methods please?
>
> Thanks and Best Regards
> Mohan
Regards,
Rainer
>
> Rainer Jung-3 wrote:
>> Mohan2005 schrieb:
>>> Hello!
>>>
>>> The documentation says the following on the Busyness Method...
>>>
>>> QUOTE
>>> If set to B[usyness] the balancer will pick the worker with the lowest
>>> current load, based on how many requests the worker is currently serving.
>>> This number is divided by the workers lbfactor, and the lowest value
>>> (least
>>> busy) worker is picked. This method is especially interesting, if your
>>> request take a long time to process, like for a download application.
>>> END QUOTE
>>>
>>> What is defined as "take a long time", is it 30 sec, 40 sec, or more ?
>> Let us rephrase this. Busyness is especially useful, if the number of
>> parallel requests you can handle is your limiting factor. Suppose you
>> need to handle very high concurrency, like e.g. 10.000 parallel
>> requests. Then you might come close to how many connections your
>> components (OS, web server, Tomcat, etc.) can handle and you need to
>> balance with respect to the expensive ressource "connections" instead of
>> CPU etc.
>>
>> Now how does parallelity relate to long running requests?
>>
>> Parallelity = Throughput * ResponseTime
>>
>> So given some fixed throughput, parallelity grows proportional to
>> reponse times. Talking about long response times is thus a simplified
>> rephrasing of talking about high concurrency.
>>
>> If you have 10 request per second (not a high load), but the response
>> time is 5 minutes, then you will end up with about 3.000 parallel
>> requests and this could be a good scenario for busyness method.
>>
>>> and
>>> from the clarifications I have got from this forum, the nodes "load" is
>>> determined by it network latency using cping and cping. These I believe
>>> are
>> Who told you that? cping/cpong have nothing to do with load decisions.
>> They only help in deciding, if a worker is in error status or not. Load
>> is distributed between all nodes that are not in error. To which of
>> those nodes a request goes is not decided by cping cpong.
>>
>>> used by all load-balancer methods to determine a nodes health. So
>>> checking
>>> the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or the
>>> Traffic are just checking the counters of a node that is more active than
>>> the other nodes.
>>>
>>> Essentially what all these methods does is check a node's health by
>>> cping,
>>> cping (Network latency) , and if it responds in good time, then check
>>> either
>> yes
>>
>>> the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least
>>> 'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or
>>> "Bytes IN/OUT" if "Traffic" method is used.
>> yes
>>
>>> Is this summary of mod_jk in non-technical perspective accurate ??
>>>
>>>
>>> Thanks
>>> 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: Busyness Method and others...
Posted by Mohan2005 <mo...@roomsnet.com>.
Hello Rainer;
Thanks again for taking the time and for the information.
if I quote you
"
Who told you that? cping/cpong have nothing to do with load decisions.
They only help in deciding, if a worker is in error status or not. Load
is distributed between all nodes that are not in error. To which of
those nodes a request goes is not decided by cping cpong.
"
But the million dollar question :-) is , if cping,cpong does not determine a
nodes HEALTH OR LOAD as you put it, how is the LOAD on a node determined
(what is used to monitor the health/load of nodes) technically by the
methods please?
Thanks and Best Regards
Mohan
Rainer Jung-3 wrote:
>
> Mohan2005 schrieb:
>> Hello!
>>
>> The documentation says the following on the Busyness Method...
>>
>> QUOTE
>> If set to B[usyness] the balancer will pick the worker with the lowest
>> current load, based on how many requests the worker is currently serving.
>> This number is divided by the workers lbfactor, and the lowest value
>> (least
>> busy) worker is picked. This method is especially interesting, if your
>> request take a long time to process, like for a download application.
>> END QUOTE
>>
>> What is defined as "take a long time", is it 30 sec, 40 sec, or more ?
>
> Let us rephrase this. Busyness is especially useful, if the number of
> parallel requests you can handle is your limiting factor. Suppose you
> need to handle very high concurrency, like e.g. 10.000 parallel
> requests. Then you might come close to how many connections your
> components (OS, web server, Tomcat, etc.) can handle and you need to
> balance with respect to the expensive ressource "connections" instead of
> CPU etc.
>
> Now how does parallelity relate to long running requests?
>
> Parallelity = Throughput * ResponseTime
>
> So given some fixed throughput, parallelity grows proportional to
> reponse times. Talking about long response times is thus a simplified
> rephrasing of talking about high concurrency.
>
> If you have 10 request per second (not a high load), but the response
> time is 5 minutes, then you will end up with about 3.000 parallel
> requests and this could be a good scenario for busyness method.
>
>> and
>> from the clarifications I have got from this forum, the nodes "load" is
>> determined by it network latency using cping and cping. These I believe
>> are
>
> Who told you that? cping/cpong have nothing to do with load decisions.
> They only help in deciding, if a worker is in error status or not. Load
> is distributed between all nodes that are not in error. To which of
> those nodes a request goes is not decided by cping cpong.
>
>> used by all load-balancer methods to determine a nodes health. So
>> checking
>> the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or the
>> Traffic are just checking the counters of a node that is more active than
>> the other nodes.
>>
>> Essentially what all these methods does is check a node's health by
>> cping,
>> cping (Network latency) , and if it responds in good time, then check
>> either
>
> yes
>
>> the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least
>> 'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or
>> "Bytes IN/OUT" if "Traffic" method is used.
>
> yes
>
>>
>> Is this summary of mod_jk in non-technical perspective accurate ??
>>
>>
>> Thanks
>> 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/Busyness-Method-and-others...-tp14690721p14712091.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: Busyness Method and others...
Posted by Rainer Jung <ra...@kippdata.de>.
Mohan2005 schrieb:
> Hello!
>
> The documentation says the following on the Busyness Method...
>
> QUOTE
> If set to B[usyness] the balancer will pick the worker with the lowest
> current load, based on how many requests the worker is currently serving.
> This number is divided by the workers lbfactor, and the lowest value (least
> busy) worker is picked. This method is especially interesting, if your
> request take a long time to process, like for a download application.
> END QUOTE
>
> What is defined as "take a long time", is it 30 sec, 40 sec, or more ?
Let us rephrase this. Busyness is especially useful, if the number of
parallel requests you can handle is your limiting factor. Suppose you
need to handle very high concurrency, like e.g. 10.000 parallel
requests. Then you might come close to how many connections your
components (OS, web server, Tomcat, etc.) can handle and you need to
balance with respect to the expensive ressource "connections" instead of
CPU etc.
Now how does parallelity relate to long running requests?
Parallelity = Throughput * ResponseTime
So given some fixed throughput, parallelity grows proportional to
reponse times. Talking about long response times is thus a simplified
rephrasing of talking about high concurrency.
If you have 10 request per second (not a high load), but the response
time is 5 minutes, then you will end up with about 3.000 parallel
requests and this could be a good scenario for busyness method.
> and
> from the clarifications I have got from this forum, the nodes "load" is
> determined by it network latency using cping and cping. These I believe are
Who told you that? cping/cpong have nothing to do with load decisions.
They only help in deciding, if a worker is in error status or not. Load
is distributed between all nodes that are not in error. To which of
those nodes a request goes is not decided by cping cpong.
> used by all load-balancer methods to determine a nodes health. So checking
> the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or the
> Traffic are just checking the counters of a node that is more active than
> the other nodes.
>
> Essentially what all these methods does is check a node's health by cping,
> cping (Network latency) , and if it responds in good time, then check either
yes
> the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least
> 'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or
> "Bytes IN/OUT" if "Traffic" method is used.
yes
>
> Is this summary of mod_jk in non-technical perspective accurate ??
>
>
> Thanks
> 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