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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
